home / skills / dicklesworthstone / meta_skill / error-handling-base

error-handling-base skill

safe

This skill guides explicit, contextual error handling to improve clarity, observability, and reliability across applications.

npx playbooks add skill dicklesworthstone/meta_skill --skill error-handling-base

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.3 KB

---
id: error-handling-base
name: Error Handling Base
description: >-
  Foundation for error handling patterns. This is a base skill designed
  to be extended by language-specific error handling skills.
tags: [error-handling, foundation, example]
---

# Error Handling Base

> **Core insight:** Good error handling is about communication - to users, developers, and monitoring systems.

## Rules

- Always handle errors explicitly - never ignore them
- Use meaningful error messages that describe what went wrong
- Include context in error messages (what was being attempted)
- Log errors at appropriate levels (error vs warning vs info)
- Distinguish between recoverable and unrecoverable errors

## Pitfalls

- Swallowing exceptions without logging
- Using generic error messages like "An error occurred"
- Exposing internal implementation details in user-facing errors
- Catching broad exception types when specific ones are needed

## Examples

```
// Bad: Generic error
throw new Error("Error");

// Good: Descriptive error with context
throw new Error(`Failed to parse config file '${filename}': ${parseError.message}`);
```

## Checklist

- [ ] All error paths are handled explicitly
- [ ] Error messages are actionable and descriptive
- [ ] Sensitive information is not leaked in errors
- [ ] Errors are logged before being re-thrown or converted

Overview

This skill provides a compact, language-agnostic foundation for error handling patterns you can extend in language-specific implementations. It focuses on communicative error design: clear messages, contextual information, and appropriate logging levels. Use it as the baseline checklist and rule set when designing or reviewing error flows in CLI tools, services, or libraries.

How this skill works

The skill codifies core rules and common pitfalls for error handling and supplies a small checklist to verify implementation quality. It inspects error messages, logging placement, and whether errors are classified as recoverable or unrecoverable. When extended, language-specific adapters enforce these rules in code reviews, linters, or runtime wrappers.

When to use it

Designing error handling for a new CLI, service, or library
Reviewing or auditing existing error flows and logs
Implementing language-specific error wrappers or adapters
Creating user-facing error messages for tools or APIs
Building automated checks or linters for error-related patterns

Best practices

Always handle errors explicitly; never swallow exceptions without logging
Write actionable, descriptive messages that include the operation and context
Classify errors as recoverable or unrecoverable and handle accordingly
Log errors at the appropriate level and include context, not secrets
Avoid exposing internal implementation details in user-facing messages

Example use cases

Wrap parsing logic to throw errors like: Failed to parse config 'X': reason
Audit a codebase for generic error messages and replace them with contextual ones
Add middleware that converts low-level exceptions into user-friendly messages
Create unit tests that assert all error paths are covered and logged
Extend the base rules into a Rust-specific crate that enforces checks at build or runtime

FAQ

Should I always log full error details?

Log full details for internal monitoring and debugging, but redact or omit sensitive data before exposing messages to users.

How do I decide recoverable vs unrecoverable?

Recoverable errors are transient or user-fixable (network, validation); unrecoverable errors indicate invariant violations or corrupt state and usually require abort or escalation.