error-handler-advisor

Identify and improve Rust error handling patterns using unwrap(), expect(), and panic!().

2|1|Updated Oct 31, 2025
One-click install
npx skills add https://github.com/EmilLindfors/claude-marketplace --skill error-handler-advisor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: error-handler-advisor
Source: https://github.com/EmilLindfors/claude-marketplace/tree/main/plugins/rust-error-handling/skills/error-handler-advisor
Command: npx skills add https://github.com/EmilLindfors/claude-marketplace --skill error-handler-advisor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Proactively reviews error handling patterns and suggests improvements using Result types, propagation, and context.

Core Features & Use Cases

  • Unwrap/expect usage improvements
  • Custom error types with thiserror
  • Error propagation with ?
  • Contextual error messages

Quick Start

Refactor unwraps to ? with context.

Frequently Asked Questions about error-handler-advisor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I replace unwrap() and expect() calls in Rust production code?

Replace unwrap() and expect() with the ? operator for error propagation, which returns errors to the caller instead of panicking. Pair this with Result return types and custom error definitions using thiserror to provide typed, contextual error information.

What's the best way to add context to error messages in Rust?

Use anyhow's Context trait or thiserror's #[from] and custom message fields to attach contextual information to errors. This preserves the error chain and helps debugging by showing where and why an error occurred.

When should I use thiserror versus anyhow for Rust error handling?

Use thiserror to define custom, typed error types for libraries and structured error handling. Use anyhow for applications where error chains and flexible context matter more than type specificity.

How do I handle Option types with proper error context instead of unwrap()?

Convert Option to Result using ok_or() or ok_or_else(), then propagate with ?. This lets you define context and error types instead of panicking on None values.

Can I apply error handling improvements to existing Rust code without rewriting it completely?

Yes. Incrementally refactor high-risk unwrap() and expect() calls to ? propagation, introduce thiserror types for new error paths, and add Context to existing Result chains without touching working code.