I just published erra, a small crate that fills a specific gap in Rust error handling.

The problem it solves: ? propagates errors faithfully but strips all call-site context. The usual fix is anyhow::Context, which works well in applications but erases the error type. Once an error enters anyhow::Error, the only structured recovery path is a runtime downcast, which the compiler cannot verify.

erra lets you annotate any Result with a string at the call site while keeping E fully typed:

rust

use erra::ResultExt;

fn load_config(path: &str) -> Result<String, erra::Error<std::io::Error>> {
std::fs::read_to_string(path).annotate("reading application config")
}

The annotated error is still an io::Error inside. Callers can pattern match on it at compile time, no downcast needed.

A few design properties that guided it:

• Zero dependencies, including no proc-macro

• no_std compatible; bare-metal targets with no allocator can use the static string path

• From<E> is deliberately not implemented, so ? cannot silently wrap an error with no context

• On the Ok path, .annotate() compiles to a zero-cost identity in release builds

It is not a replacement for anyhow in application code, and it is not a replacement for thiserror at public API boundaries. It is for the call sites in between, where you want context without giving up the type.

Docs: docs.rs/erra
Source: github.com/ZaudRehman/erra

Feedback welcome, especially if you run into cases where the API does not compose well with something in your codebase.

1 post - 1 participant

Read full topic