Summary
Design and standardize std/errors API for practical dataflow usage in Neva.
Why
Current std/errors has minimal surface (New, Must, Lift) and does not define a complete, idiomatic toolkit for wrapping, context enrichment, matching, chain traversal, and conversion/interoperability scenarios.
Scope
- Define required use-cases first.
- Audit which use-cases are already covered and where gaps exist.
- Propose concrete API shape and naming.
Inputs to review
- Go stdlib patterns (
errors.Is, errors.As, errors.Join, %w semantics)
- Rust ecosystem ideas (not Result migration; only error-tooling ergonomics)
- Existing Neva constraints: explicit dataflow,
res/err outports, ? err-guard.
Non-goals
- No migration to Rust-style
Result<T,E> language contract.
- No change to
res/err outport model.
Candidate use-cases
- Create/wrap with context
- Check by kind/category/sentinel
- Unwrap / iterate chain
- Normalize external errors into Neva
error
- Aggregate multiple errors where relevant
- Render error chain for logs/debug
Deliverables
- Proposed API list for
std/errors with component signatures and examples
- Rationale/tradeoffs for each API item
- Migration notes for existing code
Related
Summary
Design and standardize
std/errorsAPI for practical dataflow usage in Neva.Why
Current
std/errorshas minimal surface (New,Must,Lift) and does not define a complete, idiomatic toolkit for wrapping, context enrichment, matching, chain traversal, and conversion/interoperability scenarios.Scope
Inputs to review
errors.Is,errors.As,errors.Join,%wsemantics)res/erroutports,?err-guard.Non-goals
Result<T,E>language contract.res/erroutport model.Candidate use-cases
errorDeliverables
std/errorswith component signatures and examplesRelated
errorrepresentation: Internal error representation: tagged union model (keep res/err contract) #1045maybetype must be tagged union #907