Ohno
High-quality error handling for Rust.
Ohno combines error wrapping, enrichment messages stacking, backtrace capture, and procedural macros into one ergonomic crate for comprehensive error handling.
Key Features
#[derive(Error)]: Derive macro for automaticstd::error::Error,Display,Debugimplementations#[error]: Attribute macro for creating error types#[enrich_err("...")]: Attribute macro for automatic error enrichment with file and line information.ErrorExt: Trait that provides additional methods for ohno error types, it’s implemented automatically for all ohno error typesOhnoCore: Core error type that wraps source errors, captures backtraces, and holds enrichment entriesAppError: Application-level error type for general application errors
Quick Start
use ;
;
Derive Macro
Derive macro for automatically implementing error traits.
When applied to a struct or enum containing an OhnoCore field,
this macro automatically implements std::error::Error, std::fmt::Display, std::fmt::Debug, and From conversions.
Note:
From<std::convert::Infallible>is implemented by default and calls viaunreachable!macro.
use ;
ohno::error
The #[ohno::error] attribute macro is a convenience wrapper that automatically adds a OhnoCore
field to your struct and applies #[derive(Error)]. This is the simplest way to create error types
without manually managing the error infrastructure.
The attribute always adds that field and always generates the error representation from it, so
no field may be marked with #[error]. Remove the marker to keep the field as data, or use
#[derive(Error)] directly to place the core by hand.
A field of type OhnoCore may still be declared, and is then treated as data rather than as the
error: it is passed to the generated constructors like any other field, appears in the generated
Debug, and can be referenced from a #[display(...)] template — but it is never read for
source(), the backtrace, or enrichment, which all come from the injected field.
// Simple error without extra fields
;
// Error with multiple fields
Display Error Override
The #[display("...")] attribute allows you to customize the main error message
while preserving the underlying error as a cause in the error chain.
use PathBuf;
// Usage
let error = caused_by;
// Output: "Failed to read config with path: /etc/config.toml\nCaused by:\n\tfile not found"
The template string supports field interpolation using {field_name} syntax. The underlying
error (if any) is automatically shown as “Caused by:” in the error chain. If the inner error
has no source, only the custom message is displayed.
Fields of a tuple struct are interpolated by index, using {0}, {1}, and so on.
Format Arguments
Anything that is not a plain field reference is passed as a positional argument, with
format!’s placeholder and argument-counting semantics:
use PathBuf;
Positional arguments are implicitly scoped to self, so a field is referenced by its bare
name. Unlike thiserror, neither the self. prefix nor the leading-dot form is accepted:
| Argument | Accepted |
|---|---|
path.display() |
yes |
self.path.display() |
no, the self. prefix is implicit |
.path.display() |
no, not a valid expression |
Automatic Constructors
By default, #[derive(Error)] automatically generates new() and caused_by() constructor methods:
// The derive macro automatically generates:
// - ConfigError::new(path: String) -> Self
// - ConfigError::caused_by(path: String, error: impl Into<Box<dyn Error...>>) -> Self
let error = new;
let error_with_cause = caused_by;
Disabling Automatic Constructors:
Use #[no_constructors] to disable automatic generation when you need custom constructors:
use ;
Automatic From Implementations
The #[from(Type1, Type2, ...)] attribute automatically generates From<Type> implementations
for the specified types. Other fields in the struct are defaulted using Default::default().
// This generates:
// impl From<std::io::Error> for MyError { ... }
// impl From<std::fmt::Error> for MyError { ... }
let io_err = new;
let my_err: MyError = io_err.into; // Works automatically
// optional_field = None, code = 0 (defaulted)
Note: Error’s fields must implement Default when using #[from] to ensure they can be properly initialized.
Error Enrichment
The #[enrich_err("message")] attribute macro adds error enrichment with file and line info to function errors.
Functions annotated with #[enrich_err("message")] automatically wrap any returned Result. If
the function returns an error, the macro injects a message, including file and line information, into the error chain.
Requirements:
- The function must return a type that implements the
map_errmethod (such asResultorPoll) - The error type must implement the
Enrichabletrait (automatically implemented for all ohno error types)
Supported syntax patterns:
- Simple string literals:
- Parameter interpolation:
- Complex expressions with method calls:
use Path;
- Multiple expressions and calculations:
- Mixed parameter interpolation and format expressions:
All patterns include file and line information automatically:
;
// Error output will include: "failed to open file (at src/main.rs:42)"
AppError
For applications that need a simple, catch-all error type, use AppError. It
automatically captures backtraces and can wrap any error type.
To avoid accidental usage in libraries, AppError is only available when the app-err
feature is enabled.
Example usage:
use AppError;
Error Labeling
ErrorLabel is a low-cardinality string label for errors, intended for use as a metric
tag or structured log field. Labels must be chosen from a small, bounded set known at
development time to avoid high-cardinality metric series.
use ErrorLabel;
let label: ErrorLabel = from_static;
assert_eq!;
let label = from_parts;
assert_eq!;
Use ErrorLabel::from_error_chain to walk an error’s source
chain and build a dotted label from recognized errors:
use ErrorLabel;
let io_err = new;
let label = from_error_chain;
assert_eq!;
Types that carry an ErrorLabel can implement the Labeled trait to expose it
uniformly via Labeled::label.