Skip to content

Analyzers: flag a discarded Outcome/Outcome<T> result #233

Description

@Reefact

Problem

validator.Check(request); — an invocation returning Outcome/Outcome<T> used as a bare expression statement (or assigned to a discard) — compiles silently and loses the error. This is the library's central failure mode (a lost failure), yet no rule flags it: FCE016 covers only the rarer discarded error.ToException() case.

Impact

The single largest gap between the library's thesis ("an error is a value a caller returns and inspects") and what the analyzers enforce. A silently dropped Outcome is strictly worse than a dropped ToException(), and today only the latter is caught.

Direction

  • Mirror FCE016's discard detection, keyed on the invocation's return type rather than a method name; Warning severity, on by default, consistent with FCE016.
  • ID note: the audit proposed FCE019, but FCE019–FCE021 are taken by the in-flight Outcome.Try analyzers (branch claude/outcome-try-feature-z1u1n4) — use the next free ID after that branch lands.
  • Usual completion: descriptor, EN+FR doc pages, per-rule tests (including the compliant assignment/await/return cases and sibling-rule ownership).

Acceptance criteria

  • A bare-statement or discarded Outcome/Outcome<T> invocation produces the new diagnostic; assigned, returned, awaited-and-used, and chained results do not.
  • The rule ships in the bundled analyzer set with bilingual docs and tests, and the analyzer README table row matches the descriptor.

Context

Surfaced by the 2026-07-20 architecture, design & ecosystem audit (doc/handwritten/for-maintainers/audit/2026-07-20-firstclasserrors-architecture-and-design-audit.md, §12.3/§13.3(d)/§14-C6; branch claude/firstclasserrors-audit-83gap7).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions