go-error-handling

Standardize Go error handling with wrapping, sentinel values, and type inspection.

2|Updated Jan 3, 2026
One-click install
npx skills add https://github.com/jovermier/cc-stack-marketplace --skill go-error-handling-jovermier
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: go-error-handling
Source: https://github.com/jovermier/cc-stack-marketplace/tree/main/plugins/cc-go/skills/go-error-handling
Command: npx skills add https://github.com/jovermier/cc-stack-marketplace --skill go-error-handling-jovermier

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Go projects often suffer from uncontextual error handling, fragile type checks, and scattered error wrapping. This Skill provides a cohesive guide to implement robust error handling using the Go standard library, enabling consistent error propagation and easier debugging.

Core Features & Use Cases

  • Wrap errors with context using %w to preserve error types across boundaries.
  • Define and use custom error types for domain-specific failures.
  • Error inspection with errors.Is and errors.As to differentiate failure modes.
  • Sentinel (package-level) errors to signal expected conditions in APIs.
  • Practical guidelines for when to wrap, when to return, and how to structure error flows in services.

Quick Start

To implement robust error handling in a Go service, wrap repository errors at the service boundary with contextual messages and check for sentinel errors at the caller. For example, wrap a db error with "getting item: %w" and use errors.Is to detect ErrNotFound.

Frequently Asked Questions about go-error-handling

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

FAQPage Schema
How do I wrap Go errors with context across service boundaries?

Wrap Go errors with context using the %w verb in fmt.Errorf to preserve the original error type while adding descriptive messages. This maintains the original error chain when errors cross repository boundaries and service layers for easier debugging.

What is the difference between errors.Is and errors.As in Go?

errors.Is checks if an error matches a specific sentinel value, while errors.As extracts and casts custom error types from the chain. Use errors.Is for exact matching and errors.As for type inspection and extraction.

When should I use sentinel errors vs custom error types in Go?

Use sentinel errors for expected package-level API conditions like ErrNotFound, and custom error types when you need to carry domain-specific failure data. Sentinel values signal expected states, while custom types enable errors.As extraction of structured failure data.

How do I preserve error context when propagating Go errors to the API surface?

Preserve Go error context at API surfaces by wrapping repository errors with %w at service boundaries and defining custom error types. This ensures failure modes remain differentiated and contextual information stays intact when errors reach the API layer.

Why does my Go error type check fail after wrapping the error?

Go error type checks fail after wrapping if you use direct comparison instead of errors.As. Wrapping with %w creates a new error chain, requiring errors.As to traverse the chain and properly extract the underlying custom error type.