golang-error-handling

Enforce consistent error wrapping and inspection in Go applications.

Updated Oct 1, 2024
One-click install
npx skills add https://github.com/mrlorentx/.files --skill golang-error-handling-mrlorentx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-error-handling
Source: https://github.com/mrlorentx/.files/tree/main/ai/claude/skills/golang-error-handling
Command: npx skills add https://github.com/mrlorentx/.files --skill golang-error-handling-mrlorentx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Go developers often struggle with inconsistent error handling, lack of context, and poor propagation, leading to hard-to-debug failures in production.

Core Features & Use Cases

  • Wrapping with %w and using errors.Is/As to build rich error chains
  • Sentinel errors and custom error types to carry structured data
  • The single handling rule with optional structured logging (slog) and production-ready errors (samber/oops)
  • Panic/recover guidelines for unrecoverable states and safe recovery points
  • HTTP request logging middleware patterns for structured traces

Quick Start

Refactor an existing Go function to wrap errors with context using %w and propagate to the caller.

Frequently Asked Questions about golang-error-handling

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

FAQPage Schema
What is the best way to handle Go errors at scale without losing context?

Idiomatic Go error handling at scale requires wrapping errors with %w to preserve original context and using errors.Is/As for inspection. It enforces consistent propagation rules and structured logging with slog to prevent hard-to-debug production failures.

How do I wrap Go errors properly using %w and inspect them with errors.Is and errors.As?

Wrap Go errors with %w to build rich error chains and inspect them using errors.Is for specific sentinel values and errors.As to extract structured data from custom error types during code reviews.

Does this Go error handling approach work with slog for structured production logging?

Yes, this approach implements a single handling rule with optional structured logging using slog. It also supports production-ready errors with samber/oops and HTTP request logging middleware patterns for structured traces.

When should I use panic and recover for unrecoverable states in Go applications?

Use panic and recover in Go applications only for unrecoverable states and safe recovery points. Standard execution paths should wrap errors with %w and propagate them to the caller for consistent handling.

Why does my Go application fail to debug errors in production despite logging?

Lack of context and poor propagation make Go errors hard to debug in production. Applying consistent wrapping with %w and structured logging with slog or samber/oops provides necessary traces and metadata to fix failures.