Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
zhanghandong avatar

M06 Error Handling

  • 840 installs
  • 1.3k repo stars
  • Updated May 24, 2026
  • zhanghandong/rust-skills

This is a copy of m06-error-handling by actionbook - installs and ranking accrue to the original listing.

m06-error-handling is a Rust skill that teaches library-specific error enums and application-level handling with thiserror and anyhow for developers who need Send+Sync, chainable errors in production Rust code.

About

m06-error-handling is a zhanghandong/rust-skills module that separates library error design from application error handling in Rust. The skill prescribes five library principles: define specific error types instead of anyhow, implement std::error::Error, expose matchable variants, chain source errors, and keep types Send + Sync for async. Worked examples use thiserror-derived enums such as DatabaseError with ConnectionFailed and query variants. Developers reach for m06-error-handling when shipping Rust crates or services where opaque errors frustrate downstream callers or async runtimes.

  • 5 core principles for library error design
  • Defines specific error types instead of using anyhow in libraries
  • Implements std::error::Error with source chaining and Send + Sync
  • Provides concrete error variants for easy matching by consumers
  • Includes ready-to-use thiserror example with public Result alias

M06 Error Handling by the numbers

  • 840 all-time installs (skills.sh)
  • +9 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill m06-error-handling

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs840
repo stars1.3k
Security audit3 / 3 scanners passed
Last updatedMay 24, 2026
Repositoryzhanghandong/rust-skills

How do you design Rust library error types?

Create robust, user-friendly error types and handling patterns in Rust libraries and applications.

Who is it for?

Rust developers publishing libraries or async services who need explicit, matchable error types.

Skip if: Quick scripts where a single anyhow::Error bubble is acceptable and no public API surface exists.

When should I use this skill?

A Rust crate needs custom error enums, error chains, or library-vs-app handling separation.

What you get

Typed error enums, source-chained variants, and library-vs-application handling guidance.

  • Library error enum definitions
  • Error-handling pattern guide

By the numbers

  • Documents 5 core library error-handling principles

Files

SKILL.mdMarkdownGitHub ↗

Error Handling

Layer 1: Language Mechanics

Core Question

Is this failure expected or a bug?

Before choosing error handling strategy:

  • Can this fail in normal operation?
  • Who should handle this failure?
  • What context does the caller need?

---

Error → Design Question

PatternDon't Just SayAsk Instead
unwrap panics"Use ?"Is None/Err actually possible here?
Type mismatch on ?"Use anyhow"Are error types designed correctly?
Lost error context"Add .context()"What does the caller need to know?
Too many error variants"Use Box<dyn Error>"Is error granularity right?

---

Thinking Prompt

Before handling an error:

1. What kind of failure is this?

  • Expected → Result<T, E>
  • Absence normal → Option<T>
  • Bug/invariant → panic!
  • Unrecoverable → panic!

2. Who handles this?

  • Caller → propagate with ?
  • Current function → match/if-let
  • User → friendly error message
  • Programmer → panic with message

3. What context is needed?

  • Type of error → thiserror variants
  • Call chain → anyhow::Context
  • Debug info → anyhow or tracing

---

Trace Up ↑

When error strategy is unclear:

"Should I return Result or Option?"
    ↑ Ask: Is absence/failure normal or exceptional?
    ↑ Check: m09-domain (what does domain say?)
    ↑ Check: domain-* (error handling requirements)
SituationTrace ToQuestion
Too many unwrapsm09-domainIs the data model right?
Error context designm13-domain-errorWhat recovery is needed?
Library vs app errorsm11-ecosystemWho are the consumers?

---

Trace Down ↓

From design to implementation:

"Expected failure, library code"
    ↓ Use: thiserror for typed errors

"Expected failure, application code"
    ↓ Use: anyhow for ergonomic errors

"Absence is normal (find, get, lookup)"
    ↓ Use: Option<T>

"Bug or invariant violation"
    ↓ Use: panic!, assert!, unreachable!

"Need to propagate with context"
    ↓ Use: .context("what was happening")

---

Quick Reference

PatternWhenExample
Result<T, E>Recoverable errorfn read() -> Result<String, io::Error>
Option<T>Absence is normalfn find() -> Option<&Item>
?Propagate errorlet data = file.read()?;
unwrap()Dev/test onlyconfig.get("key").unwrap()
expect()Invariant holdsenv.get("HOME").expect("HOME set")
panic!Unrecoverablepanic!("critical failure")

Library vs Application

ContextError CrateWhy
LibrarythiserrorTyped errors for consumers
ApplicationanyhowErgonomic error handling
MixedBoththiserror at boundaries, anyhow internally

Decision Flowchart

Is failure expected?
├─ Yes → Is absence the only "failure"?
│        ├─ Yes → Option<T>
│        └─ No → Result<T, E>
│                 ├─ Library → thiserror
│                 └─ Application → anyhow
└─ No → Is it a bug?
        ├─ Yes → panic!, assert!
        └─ No → Consider if really unrecoverable

Use ? → Need context?
├─ Yes → .context("message")
└─ No → Plain ?

---

Common Errors

ErrorCauseFix
unwrap() panicUnhandled None/ErrUse ? or match
Type mismatchDifferent error typesUse anyhow or From
Lost context? without contextAdd .context()
cannot use ?Missing Result returnReturn Result<(), E>

---

Anti-Patterns

Anti-PatternWhy BadBetter
.unwrap() everywherePanics in production.expect("reason") or ?
Ignore errors silentlyBugs hiddenHandle or propagate
panic! for expected errorsBad UX, no recoveryResult
Box<dyn Error> everywhereLost type infothiserror

---

Related Skills

WhenSee
Domain error strategym13-domain-error
Crate boundariesm11-ecosystem
Type-safe errorsm05-type-driven
Mental modelsm14-mental-model

Related skills

How it compares

Pick m06-error-handling over generic Rust tutorials when designing public crate error APIs, not when learning basic Result unwrap patterns.

FAQ

Should Rust libraries use anyhow?

m06-error-handling advises against anyhow in library crates. Libraries should define specific error enums with thiserror, implement std::error::Error, expose variants for matching, and chain source errors for debugging.

Why must Rust library errors be Send + Sync?

m06-error-handling requires Send + Sync error types so library failures propagate safely through async runtimes and thread pools. Without these bounds, error values cannot cross await points or shared tasks.

Is M06 Error Handling safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.