Source status: no status is stated in the source document, so none is assigned here. Do not treat this page as a finalized specification. The normative rules are in the Technical Specification.

Error Handling System¶

The language will use explicit, typed failure handling.

1. Expected Failures¶

Functions must declare possible failure outcomes.

Examples: - Invalid input - Missing resources - Permission denied - Network unavailable - Database failure - Insufficient funds

2. Result Types¶

Operations that can fail must return an explicit Result containing either:

• Success: The expected return value.
• Failure: A declared error type describing what went wrong.

3. Error Handling Rules¶

• Failures cannot be silently ignored.
• Callers must handle failures or explicitly propagate them.
• Generic catch-all handlers should not conceal unexpected failures.
• Error information must preserve its original cause.
• Recovery operations must establish that the system is in a valid state.
• A function cannot report success after an unsuccessful operation.

4. Unexpected Failures¶

Unexpected failures must remain distinguishable from declared failures.

The runtime must prevent them from being mistaken for ordinary successful outcomes.

Design Goal¶

AI-generated software must account for failure as part of normal program design, rather than treating it as an afterthought.

Source and authority¶

This page migrates ERRORS.md in full. It is an explanatory / implementation document, not the normative specification. Where it simplifies a rule, the Technical Specification governs. The original file is preserved in source-original/LANG/.