agentsclimarketplace
Sign in

Rust error handling

Skill Amey-Thakur/AI-SKILLS/skills/systems-languages/rust-error-handling

Design Rust error types with the thiserror/anyhow split, context chains, and a deliberate panic policy. Use when structuring errors in Rust libraries and applications.From its SKILL.md

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill rust-error-handling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.9 KB, 656 tokens by cl100k_base, as published. Nobody here has run it

Rust error handling

Result makes every failure path visible in the signature. The design work is choosing which errors are part of your API (typed, matchable) and which are just reports for a human (context-rich, opaque).

Method

  1. Split by audience: libraries type, applications report. Libraries expose concrete error enums (callers must be able to match and react); thiserror derives the boilerplate. Application and binary code uses anyhow::Result (or eyre-class) where the only consumer is a log line or exit message. The boundary between them is where typed errors get context-wrapped and become reports.
  2. Design library enums for the caller's decisions. One variant per distinct reaction: NotFound, PermissionDenied, Retryable(io::Error): not one per internal call site. Mark enums #[non_exhaustive] so adding variants is not a breaking change (see api-change-management thinking); implement std::error::Error with #[source] chains so causes stay walkable.
  3. Add context at every meaningful boundary. .with_context(|| format!("loading config {path}")) at the point that knows the filename, the query, the request id; the final report then reads as a story ("loading config X: permission denied") instead of a bare OS error. Context laid at each layer is what replaces stack traces in release builds.
  4. Use ? everywhere; convert deliberately. ? with From impls (thiserror's #[from]) keeps the happy path linear. Resist blanket Box<dyn Error> in public signatures: it types nothing and forces downcasting on callers who needed to match.
  5. Write the panic policy down. Panics are for violated invariants (bugs), never for expected failure: unwrap() in library code on I/O or parsing is a defect. Allowed: expect("invariant: queue non-empty after push") documenting why it cannot fail, tests, and prototypes clearly marked. Binaries set a top-level handler to log panics before dying (see error-tracking); servers decide panic=abort vs unwind per their supervisor model.
  6. Test the error paths as API. Assert on matched variants and on user-visible report strings for key failures; error messages are UX (see error-messages) and regress like any other output.

Boundaries

  • Do not model expected absence as error: Option for "not there", Result for "went wrong"; conflating them blurs every caller's logic.
  • Cross-FFI boundaries erase Rust errors; translate to codes/strings explicitly at the edge (see ffi-boundaries).
  • Async cancellation and task join errors are control flow, not domain errors; handle them at the runtime boundary rather than threading them through domain enums.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most error diagnosis skills give in 656 tokens

Counted across 135 of the 162 authors here whose files we hold, read 2026-09-06

  • Handle, re-throw, or log in every catch blockin 12 of 135, across 7 files
  • Use typed error classes over string messagesin 11 of 135, across 6 files
  • Log full error context server-sidein 10 of 135, across 5 files
  • Document every error code clients may receivein 9 of 135, across 4 files
  • Surface errors at the boundary where they occurin 9 of 135, across 4 files
  • Wrap React components in an ErrorBoundaryin 9 of 135, across 4 files
  • Wrap errors with context, never lose the originalin 9 of 135, across 4 files
  • Use the standard error envelope for API responsesin 9 of 135, across 4 files
  • Retry only retriable errors, never 4xx client errorsin 8 of 135, across 3 files
  • Retry transient failures with exponential backoff and jitterin 8 of 135
  • Show users friendly messages without technical detailsin 7 of 135, across 3 files
  • Use the Result pattern for expected failuresin 7 of 135, across 5 files

Said here and by no other author read

  • Use typed error enums in libraries and anyhow in applications
  • Give error enums one variant per distinct reaction
  • Mark library error enums #[non_exhaustive]
  • Implement std::error::Error with #[source] chains
  • Add context at every meaningful boundary
  • Use ? everywhere and convert deliberately

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.