agentsclimarketplace

Rust error handling

Skill fusengine/agents/plugins/rust-expert/skills/rust-error-handling

Redefining development through cognitive automation and collaborative agent systems.

Install
npx -y skills add fusengine/agents --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

  • 22 stars22 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.

What its author says it does

Copied from the file, not written here

Use when designing Rust error handling — picking thiserror for libraries vs anyhow for applications, building typed error enums, converting errors with #[from], and deciding recoverable errors vs panics. Do NOT use for general ownership/borrowing (use rust-core-language) or async runtime errors specifically.

SKILL.md

3.9 KB, as published. Nobody here has run it

Rust Error Handling

The consensus split: thiserror for libraries, anyhow for applications. A library exposes a typed error its callers can match; an application wants one ergonomic error type and rich context. Getting this boundary right is the whole discipline.

Agent Workflow (MANDATORY)

  1. fuse-ai-pilot:explore-codebase — is this crate a library (published API, other code depends on it) or a binary/application? That answer picks the tool.
  2. fuse-ai-pilot:research-expert — confirm current thiserror / anyhow API before writing derives (verification chain: fuse-browser fast-path on docs.rs/thiserror and docs.rs/anyhow → Context7 → Exa).
  3. After writing, run fuse-ai-pilot:sniper and cargo clippy.

The rule

Crate kindToolWhy
Library (others depend on it)thiserrorTyped enum, #[derive(Error)], callers can match on variants
Application (binary, top level)anyhowanyhow::Result<T>, ? everywhere, .context() for breadcrumbs
Simple / dep-freehand-written std::error::ErrorNo dependency when one or two variants suffice

Critical Rules

  1. Never expose anyhow::Error in a library's public API. It erases the type, so callers cannot match or handle specific failures. Return a typed enum error. thiserror is designed to not appear in your public API — switching to/from a hand-written impl is not a breaking change.
  2. Applications use anyhow; libraries use thiserror. Do not pull anyhow into a reusable library's signatures.
  3. Add context at each layer in application code: .context("...") / .with_context(|| ...) turns "No such file or directory" into a traceable chain.
  4. #[from] for zero-boilerplate conversion, so ? lifts a source error into your enum. #[from] implies #[source] — never write both.
  5. Errors are values; panics are bugs. Use Result for anything a caller could reasonably recover from. Reserve panic!/unwrap/expect for broken invariants.

Reference Guide

Concepts

TopicReferenceLoad when
thiserror (libraries)thiserror-libraries.mdBuilding a typed error enum for a library API
anyhow (applications)anyhow-applications.mdHandling errors in a binary / top-level app
Error designerror-design.mdShaping enums, #[from] conversion, recoverable vs panic, the anyhow/thiserror boundary

Templates

TemplateLoad when
library-error.mdNeed a complete thiserror library error module
application-error.mdNeed a complete anyhow application entry point with context

Validation Checklist

  • Library errors are a typed enum deriving thiserror::Error — no anyhow in the public API
  • Application code returns anyhow::Result<T> and adds .context(...)
  • #[from] used for source conversions; no redundant #[source] alongside it
  • ? used instead of unwrap() on fallible values
  • Panics only guard genuine invariants, with a reason
  • cargo clippy clean, sniper passed

Keep looking

Skills are one crate of 328,083. 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.