Back to list
ZhangHanDong

m06-error-handling

by ZhangHanDong

Rust Developer AI Assistance System — Meta-Problem-Driven Knowledge Indexing

469🍴 53📅 Jan 23, 2026

SKILL.md


name: m06-error-handling description: "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" user-invocable: false

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"Is error granularity right?

Thinking Prompt

Before handling an error:

  1. What kind of failure is this?

    • Expected → Result<T, E>
    • Absence normal → Option
    • 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 everywhereLost type infothiserror

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

Score

Total Score

60/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

+5
最近の活動

3ヶ月以内に更新

+5
フォーク

10回以上フォークされている

+5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon