anyhow

Flexible error handling library for Rust applications. Provides anyhow::Error as a dynamic error type that can hold any error implementing std::error::Error, with context chaining (context() / with_context()), backtraces, and ergonomic ? operator usage without defining custom error types per function. The standard error handling approach for Rust application code (as opposed to library code which uses thiserror).

Evaluated Mar 06, 2026 (0d ago) v1.x
Homepage ↗ Repo ↗ Developer Tools anyhow rust error-handling result context backtrace application-errors
⚙ Agent Friendliness
71
/ 100
Can an agent use this?
🔒 Security
98
/ 100
Is it safe for agents?
⚡ Reliability
97
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
--
Documentation
92
Error Messages
92
Auth Simplicity
100
Rate Limits
100

🔒 Security

TLS Enforcement
100
Auth Strength
100
Scope Granularity
100
Dep. Hygiene
98
Secret Handling
90

MIT/Apache 2.0. Memory-safe Rust. No network. Avoid including sensitive data (passwords, tokens) in error context strings as they may be logged.

⚡ Reliability

Uptime/SLA
100
Version Stability
98
Breaking Changes
96
Error Recovery
95
AF Security Reliability

Best When

You're building a Rust application (binary/CLI/service) and want simple error propagation without defining error types — just use anyhow::Result<T> and add context with .context().

Avoid When

You're writing a library crate — use thiserror to define structured errors that library users can match on programmatically.

Use Cases

  • Handle errors in Rust agent applications without defining custom error enums for every function
  • Add rich error context to propagated errors: file.read().context('Failed to read config file')
  • Build Rust agent CLIs and tools where descriptive error messages matter more than programmatic error matching
  • Prototype Rust agent services quickly without the overhead of defining error types upfront
  • Combine errors from multiple sources (IO, HTTP, database) into a single result type

Not For

  • Rust library crates — libraries should use thiserror for typed errors that callers can match on; anyhow's dynamic errors lose type information
  • Programmatic error matching — anyhow::Error is a type-erased box; use thiserror enums when callers need to handle different error variants differently
  • WASM targets — anyhow has limited WASM support

Interface

REST API
No
GraphQL
No
gRPC
No
MCP Server
No
SDK
Yes
Webhooks
No

Authentication

Methods: none
OAuth: No Scopes: No

Local library — no authentication required. MIT/Apache 2.0 dual licensed.

Pricing

Model: open_source
Free tier: Yes
Requires CC: No

MIT/Apache 2.0 dual licensed. Zero cost.

Agent Metadata

Pagination
none
Idempotent
Full
Retry Guidance
Not documented

Known Gotchas

  • anyhow::Result<T> is an alias for Result<T, anyhow::Error> — use this return type for all application functions: fn load_config() -> anyhow::Result<Config>
  • Context vs with_context: .context('message') evaluates message eagerly; .with_context(|| format!('expensive: {}', val)) evaluates lazily — use with_context for expensive formatting
  • anyhow::bail!() macro is shorthand for return Err(anyhow::anyhow!('message')) — cleaner than constructing and returning errors manually
  • anyhow::ensure!() macro is shorthand for if !condition { bail!('message') } — for precondition checks
  • Not for library crates: if you publish a library, use thiserror — anyhow loses type information that library users need to programmatically handle errors
  • Downcast to original error: err.downcast_ref::<IoError>() — possible but loses the benefit of context chaining; better to use thiserror for types that need downcasting

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for anyhow.

$99

Scores are editorial opinions as of 2026-03-06.

5208
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered