M06 Error Handling

This cuts through Rust's error handling by asking the right questions first: is this failure expected or a bug? Instead of defaulting to unwrap or panic, it walks you through Option versus Result, thiserror versus anyhow, and when propagation with ? actually makes sense. The flowchart alone is worth it. It connects to domain modeling (m09) when you're unsure whether absence is normal, and distinguishes library code (use thiserror for typed errors) from application code (use anyhow for ergonomics). The "trace up" and "trace down" structure helps when you're stuck between too many unwraps or lost error context. Good for anyone past the basics who keeps second-guessing their error strategy.

skills.sh installs: 3.7K
GitHub stars: 1.6K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add actionbook/rust-skills --skill m06-error-handling --agent claude-code

Installs into .claude/skills of the current project.

Files

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

Pattern	Don't Just Say	Ask 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"	Is error granularity right?

Thinking Prompt

Before handling an error:

What kind of failure is this?
- Expected → Result<T, E>
- Absence normal → Option
- Bug/invariant → panic!
- Unrecoverable → panic!
Who handles this?
- Caller → propagate with ?
- Current function → match/if-let
- User → friendly error message
- Programmer → panic with message
What context is needed?
- Type of error → thiserror variants
- Call chain → anyhow::Context
- Debug info → anyhow or tracing