You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/tutorial/rewriter/node_value_checkers.md
+12-5Lines changed: 12 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -179,9 +179,16 @@ This means you should be careful when designing patterns with multiple alternati
179
179
180
180
## Error Handling
181
181
182
-
Checkers can return either:
183
-
-`True`: Check passed, continue matching
184
-
-`False`: Check failed, pattern does not match
185
-
-`MatchResult`: More detailed result with potential failure reasons
182
+
Both check functions (including condition functions and node/value-level checkers) and
183
+
rewrite functions support the same conventions for indicating failure:
186
184
187
-
If a checker raises an exception, it will be caught and treated as a match failure, allowing patterns to fail gracefully when encountering unexpected conditions.
185
+
-**`MatchResult` with `.fail()`***(recommended)*: Return `MatchResult().fail("reason", source)` to indicate failure with a descriptive reason and optional source node/value. This provides the most useful diagnostic information for debugging.
186
+
-**Raise `MatchFailureError`***(recommended)*: Import it as `from onnxscript.rewriter.rewriter import MatchFailureError` and raise `MatchFailureError("reason", source1, source2, ...)` to indicate failure associated with one or more `ir.Node` or `ir.Value` objects. Each source should be passed as a separate positional argument (do not pass a list as a single argument). This is especially convenient in utility functions called from a check or rewrite, since it avoids having to explicitly propagate failure status through the call chain.
187
+
-**Return `None` or `False`**: These indicate failure without providing a reason. They are supported but not recommended, since a failure reason is valuable for debugging why a rule did not apply.
188
+
189
+
Including a descriptive failure reason is strongly encouraged. The rewriter's tracing infrastructure
190
+
uses these reasons to report why rules failed to match, which is essential for diagnosing
191
+
issues when developing or debugging rewrite rules.
192
+
193
+
For **check functions**, success is indicated by returning `True` or a truthy `MatchResult`.
194
+
For **rewrite functions**, success is indicated by returning one or more `ir.Value` results.
0 commit comments