M06 Error Handling

作者 actionbook5c40d3ad7851無授權條款1.5K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫6 週前更新

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 用法, 什么时候用 panic

僅含說明Software Development

AI 產生的概覽

指導 Rust 錯誤處理在 Result、Option、panic、thiserror 與 anyhow 之間的選擇。

功能: 這是一個僅含說明的技能，提供 Rust 錯誤處理的決策框架。它協助代理判斷某個失敗是預期情況還是程式缺陷，再於 Result、Option、panic、thiserror 與 anyhow 之間做出選擇。內容包含速查表、決策流程圖、常見錯誤、反模式以及相關技能指引。
適用情境: 適用於撰寫或審查涉及 Result、Option、?、unwrap、expect、panic、anyhow 或 thiserror 的 Rust 程式碼。它針對何時應 panic、何時應回傳 Result、如何帶著上下文傳播錯誤，以及如何設計自訂錯誤類型等問題。
執行需求: 不需要指令碼或執行環境相依項目，僅為說明性內容。文中將 Rust 的 thiserror 與 anyhow 作為主題提及，但不要求安裝它們。

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)

"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)

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")

"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

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 ?

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

來源與署名

來源：actionbook/rust-skills位於skills/m06-error-handling提交5c40d3a

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

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?

Context	Error Crate	Why
Library	`thiserror`	Typed errors for consumers
Application	`anyhow`	Ergonomic error handling
Mixed	Both	thiserror at boundaries, anyhow internally

When	See
Domain error strategy	m13-domain-error
Crate boundaries	m11-ecosystem
Type-safe errors	m05-type-driven
Mental models	m14-mental-model

M06 Error Handling

Error Handling

Core Question

Error → Design Question

Thinking Prompt

Trace Up ↑

Trace Down ↓

Quick Reference

Library vs Application

Decision Flowchart

Common Errors

Anti-Patterns

Related Skills

來源與署名

更多來自 actionbook/rust-skills 的技能

Rust Trait Explorer

Rust Symbol Analyzer

Rust Skill Creator

Rust Router

Rust Refactor Helper

Rust Daily

更多Software Development技能

Playground

M5 Onboard

Cardputer Buddy

Web Design Guidelines

Vercel React Native Skills

Vercel React Best Practices