Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-06 07:06:54 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

knowledge(error-handling): a bare [TryFunction] call propagates its error

Browse source 
The review agent repeatedly flagged bare calls to [TryFunction] procedures
(e.g. the System Application "Xml Validation" Try* APIs) as defects,
including claims that the failure is "silently swallowed". A bare call is
an ordinary call: the error propagates as usual.

- Add negative knowledge bare-tryfunction-call-propagates-errors.md.
- Narrow ignored-tryfunction-return-disables-try-semantics to code that
  visibly expects the failure to be caught; the bad sample now shows that
  in code, and the good sample includes an intentional bare call as the
  clean control.
- Qualify "TryFunction catches all errors" in the events article and the
  "must be consumed" wording in the performance article.
- Error-handling leaf worklists both articles for bare [TryFunction] calls
  and requires the same evidence before flagging.
- Add the three paired articles to the evaluation overrides.
This commit is contained in:
Kilian Seizinger 2026-10-02 14:30:51 +02:00
parent ac249ba4c9
commit da5a28819e
8 changed files with 71 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

5
microsoft/skills/review/al-error-handling-review.md
View file

@ -48,7 +48,7 @@ Narrow the relevant files to the subset that applies to the changes under review
- The changed procedures and triggers, weighted toward `OnValidate`/`OnInsert`/`OnModify` triggers, posting and validation routines, and procedures attributed with `[ErrorBehavior(...)]` or `[TryFunction]`.
- Tokens extracted from the diff that relate to error surfacing and diagnostics (`Error`, `ErrorInfo`, `FieldError`, `TestField`, `Title`, `Message`, `DetailedMessage`, `AddAction`, `AddNavigationAction`, `RecordId`, `PageNo`, `ErrorBehavior`, `Collect`, `HasCollectedErrors`, `GetCollectedErrors`, `ClearCollectedErrors`, `ErrorType`, `Internal`, `Client`, `TryFunction`, `GetLastErrorText`, Boolean assignment).
- For the outbound HTTP call paths identified in Source, include `HttpClient`, `Get`, `Post`, `HttpResponseMessage`, response use, and caller failure handling (including `[TryFunction]` call sites) in keyword and topic matching.
- Resolve changed standalone call targets; when the target declaration has `[TryFunction]`, worklist the ignored-return rule even if the declaration itself is unchanged. Only assignment and conditional use activate try semantics.
- Resolve changed standalone call targets; when the target declaration has `[TryFunction]`, worklist both `ignored-tryfunction-return-disables-try-semantics` and `bare-tryfunction-call-propagates-errors` even if the declaration itself is unchanged. Only assignment and conditional use activate try semantics. A `Try` name prefix does not establish `[TryFunction]`; resolve the declaration.
A file enters the candidate worklist when its `keywords` intersect the extracted tokens or its topic (derived from the index entry's `path`, `title`, and `description`) matches a changed object type. Read an article's full file — its `## Best Practice` / `## Anti Pattern` bodies — only after it makes the worklist; candidate selection uses the index alone.
@ -60,7 +60,8 @@ The following targeted checks cover every current `error-handling` article:
- Developer-only invariant text is raised with default client visibility, or a user-actionable validation is hidden as `ErrorType::Internal` — `errortype-internal-vs-client-for-diagnostics`.
- `FieldError` receives a complete capitalized sentence, repeats the field caption/value, or ends the predicate with punctuation — `fielderror-default-message-logic`.
- An unguarded `FieldError` is used as though it performed a comparison, or `TestField` is forced onto a complex rule needing a tailored predicate — `fielderror-vs-testfield`.
- A resolved call target is marked `[TryFunction]` but the call is a standalone statement whose Boolean result is ignored — `ignored-tryfunction-return-disables-try-semantics`. This call-site rule supersedes the performance TryFunction article unless writes and rollback expectations are also visible.
- A resolved call target is marked `[TryFunction]`, the call is a standalone statement whose Boolean result is ignored, and the surrounding code expects the failure to be caught (a later last-error check, failure branch or result, or a loop meant to continue past failures) — `ignored-tryfunction-return-disables-try-semantics`. This call-site rule supersedes the performance TryFunction article unless writes and rollback expectations are also visible.
- A bare `[TryFunction]` call without such handling is intended propagation — `bare-tryfunction-call-propagates-errors`. It suppresses findings, including agent findings, that call the failure swallowed or ask for the result to be captured and re-raised.
- A plain `Error` represents a known actionable correction that can be expressed through `ErrorInfo` actions/navigation, or an `ErrorInfo` omits the context needed for that action — `prefer-errorinfo-for-actionable-errors`.
Once the candidate worklist is known, resolve layer-precedence conflicts per READ. Drop lower-precedence files whose normative guidance (`## Best Practice` or `## Anti Pattern`) directly contradicts a higher-precedence candidate, and record each dropped file in `suppressed` with `reason: "layer-precedence"`. Files that would have been candidates but are hidden because their layer is disabled in consumer configuration are recorded with `reason: "configuration"`. Files that never became candidates are NOT recorded in `suppressed`.