Errors
Use returns containers for predictable failure. Never author raise or try/except application control flow.
Typed outcomes
Why
Invalid input should remain a value that callers can compose. Exceptions belong to the external API being adapted, not the domain workflow.
Rules
MUST construct successful and failed pure outcomes with typedSuccessandFailurevalues[review]
MUST classify failures with typed literals or immutable variants rather than message text.[review]
MUST propagate Results throughbind,map, matching, or validated guards.[review]
MUST contain exception-raising primitives and third-party operations withsafe,impure_safe, orfuture_safein the owning adapter.[review]
MUST avoid decorating an entire domain workflow merely to convert hidden programming errors.[review]
MUST avoid unchecked.unwrap()and.failure()in production application paths.[review]
MUST avoid custom Exception subclasses used as authored control flow.[review]
MUST keep cancellation, KeyboardInterrupt, and process termination outside the recoverable failure model.[review]
Example
This complete example requires returns in the consumer environment. Its guards establish that integer conversion is bounded ASCII decimal input.
[review]
AST checks reject authored raise/try syntax. Failure-path tests and strict typing with the returns plugin verify container behavior and propagation.
Enforcement
AST checks reject authored raise/try syntax. Failure-path tests and strict typing with the returns plugin verify container behavior and propagation.