m13-domain-error_skill

This skill helps design robust domain error handling by classifying errors, guiding recovery, and applying retry, fallback, and circuit-breaker patterns.

Shell

565

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill zhanghandong/rust-skills --skill m13-domain-error

SKILL.md4.8 KB

Overview

This skill guides design of domain error handling so errors are actionable, secure, and recoverable. It focuses on categorizing errors by audience, deciding recovery strategies (retry, fallback, degrade), and providing the right context for debugging and observability. The goal is clear, consistent error types and policies that support resilient systems.

How this skill works

The skill inspects the error's audience (user, developer, ops) and maps it to recovery patterns (retry, fallback, fail-fast). It defines a domain error hierarchy and helper methods (e.g., is_retryable) and prescribes structured context and logging to trace failures. It also links recovery choices to implementation primitives like exponential backoff, circuit breakers, timeouts, and bulkheads.

When to use it

Designing error enums or typed error values for a domain
Choosing retry, fallback or fail-fast policies for operations
Defining user-facing vs internal error messages and logging
Specifying observability needs: IDs, request context, and structured fields
Creating resilience rules (circuit breakers, timeouts, bulkheads)

Best practices

Categorize errors by audience: user-friendly for end users, detailed for developers, structured for Ops
Treat transient vs permanent differently: retry with backoff only for transient errors
Include contextual data (request ID, input snapshot, call chain) for debugging
Avoid exposing internal error details in user messages; log details securely
Set limits: max attempts, max backoff, and clear circuit-breaker thresholds

Example use cases

Payment processing: classify network vs validation failures and apply retry or fail-fast according to business rules
API input validation: return typed user-facing errors with actionable guidance
Backend service calls: treat 5xx as transient with exponential backoff and circuit breaker
Feature degrade: use fallback/cached values when downstream is unavailable
SRE alerting: emit structured system errors for monitoring and escalation

FAQ

If the error is transient (network, temporary service) prefer retry with exponential backoff; if recovery by substitution is acceptable, use a fallback to preserve availability.

What context should errors carry?

Include request ID, relevant input data, and call-chain context. Use structured logging and attach context via error libraries to aid post-mortem without leaking sensitive data.