m06-error-handling
Defines strategies for error propagation and handling using Result, Option, and custom error types.
Install
mkdir -p .claude/skills/m06-error-handling && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4945" && unzip -o skill.zip -d .claude/skills/m06-error-handling && rm skill.zipInstalls to .claude/skills/m06-error-handling
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
CRITICAL: Use for error handling. Triggers: Result, Option, Error, ?, unwrap, expect, panic, anyhow, thiserror, when to panic vs return Result, custom error, error propagation, 错误处理, Result 用法, 什么时候用 panicKey capabilities
- →Differentiate between Result/Option/panic usage
- →Structure error propagation chains
- →Map domain errors to recovery actions
- →Determine error granularity
- →Verify recovery strategy
How it works
It guides the user through a decision matrix to identify whether a failure is expected or exceptional, resulting in appropriate Result/panic usage.
Inputs & outputs
When to use m06-error-handling
- →Determine if an error should panic
- →Refactor unwrap usage
- →Implement custom error propagation
- →Contextualize errors with anyhow
About this skill
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<dyn Error>" | Is error granularity right? |
Thinking Prompt
Before handling an error:
-
What kind of failure is this?
- Expected → Result<T, E>
- Absence normal → Option<T>
- 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
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)
| Situation | Trace To | Question |
|---|---|---|
| Too many unwraps | m09-domain | Is the data model right? |
| Error context design | m13-domain-error | What recovery is needed? |
| Library vs app errors | m11-ecosystem | Who 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
| Pattern | When | Example |
|---|---|---|
Result<T, E> | Recoverable error | fn read() -> Result<String, io::Error> |
Option<T> | Absence is normal | fn find() -> Option<&Item> |
? | Propagate error | let data = file.read()?; |
unwrap() | Dev/test only | config.get("key").unwrap() |
expect() | Invariant holds | env.get("HOME").expect("HOME set") |
panic! | Unrecoverable | panic!("critical failure") |
Library vs Application
| Context | Error Crate | Why |
|---|---|---|
| Library | thiserror | Typed errors for consumers |
| Application | anyhow | Ergonomic error handling |
| Mixed | Both | thiserror 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
| Error | Cause | Fix |
|---|---|---|
unwrap() panic | Unhandled None/Err | Use ? or match |
| Type mismatch | Different error types | Use anyhow or From |
| Lost context | ? without context | Add .context() |
cannot use ? | Missing Result return | Return Result<(), E> |
Anti-Patterns
| Anti-Pattern | Why Bad | Better |
|---|---|---|
.unwrap() everywhere | Panics in production | .expect("reason") or ? |
| Ignore errors silently | Bugs hidden | Handle or propagate |
panic! for expected errors | Bad UX, no recovery | Result |
| Box<dyn Error> everywhere | Lost type info | thiserror |
Related Skills
| When | See |
|---|---|
| Domain error strategy | m13-domain-error |
| Crate boundaries | m11-ecosystem |
| Type-safe errors | m05-type-driven |
| Mental models | m14-mental-model |
When not to use it
- →When the language defaults are sufficient without custom patterns
- →Simple scripts where performance/type safety isn't required
Limitations
- →Conceptual tool, not an automated error fixer
- →Requires careful application to avoid over-engineering
How it compares
It enforces a consistent architectural philosophy for error management rather than providing ad-hoc syntax fixes.
Compared to similar skills
m06-error-handling side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| m06-error-handling (this skill) | 1 | 6mo | Review | Intermediate |
| organize-modules | 1 | 2mo | Review | Intermediate |
| m04-zero-cost | 0 | 6mo | No flags | Intermediate |
| m05-type-driven | 0 | 6mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by actionbook
View all by actionbook →You might also like
organize-modules
r3bl-org
Apply private modules with public re-exports pattern for clean API design. Includes conditional visibility for docs and tests. Use when creating modules, organizing mod.rs files, or before creating commits.
m04-zero-cost
actionbook
CRITICAL: Use for generics, traits, zero-cost abstraction. Triggers: E0277, E0308, E0599, generic, trait, impl, dyn, where, monomorphization, static dispatch, dynamic dispatch, impl Trait, trait bound not satisfied, 泛型, 特征, 零成本抽象, 单态化
m05-type-driven
actionbook
CRITICAL: Use for type-driven design. Triggers: type state, PhantomData, newtype, marker trait, builder pattern, make invalid states unrepresentable, compile-time validation, sealed trait, ZST, 类型状态, 新类型模式, 类型驱动设计
minimize-rust-ffi-crate-surface
RediSearch
Remove Rust-defined C symbols that are either unused or only used in C/C++ unit tests.
upgrade-oxc
rolldown
Upgrade oxc, run codegen, and fix any breaking changes.
clean-code
gregoire78
Apply clean code practices in this repository with small, safe refactors, explicit naming, reduced complexity, and behavior-preserving changes. Use for readability improvements, technical debt cleanup, and maintainability reviews in Rust code.