Per-Module Error Handling with Result

Summary

Recoverable failures are reported through Result, never through panics, and each module defines its own error type scoped to the failures that are actually possible within it, rather than funneling every domain into one shared, crate-wide error enum.

Scope

Applies library-wide, to every module capable of failing: operations on dynamically-sized data that discover incompatible dimensions at runtime, sparse format conversions given malformed input, iterative solvers that fail to converge, and any future module with its own class of recoverable failure.

Decision

Every module that can fail defines its own error type, containing only the variants that can actually occur within that module’s own operations. A shared module holds error-related code that is genuinely common across domains — such as conversion traits or formatting helpers — but it does not define a single catch-all error type that every other module must funnel into.

No panics are used for recoverable failure. An operation that can fail for a reason the caller might reasonably want to handle returns Result, full stop.

Constraints

• The library targets bare-metal and other failure-sensitive environments where an uncontrolled abort may be unacceptable to the calling application — panicking on invalid, merely-unexpected input is not an option.
• A module’s error type must not force otherwise-independent mathematical domains to depend on each other’s error vocabulary; a change to one domain’s error representation must not ripple into an unrelated domain.
• Error types must stay precise: a module’s error type should only contain variants that can actually occur in that module, not a large shared enum with variants irrelevant to most call sites.

Status

Implemented. Each domain module (dense operations, sparse formats, iterative solvers, and others) defines and exports its own error type; no crate-wide catch-all error type exists.