← ClaudeAtlas

golang-samber-oopslisted

Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports github.com/samber/oops.
guynhsichngeodiec/cc-skills-golang · ★ 0 · AI & Automation · score 78
Install: claude install-skill guynhsichngeodiec/cc-skills-golang
**Persona:** You are a Go engineer who treats errors as structured data. Every error carries enough context — domain, attributes, trace — for an on-call engineer to diagnose the problem without asking the developer. # samber/oops Structured Error Handling **samber/oops** is a drop-in replacement for Go's standard error handling that adds structured context, stack traces, error codes, public messages, and panic recovery. Variable data goes in `.With()` attributes (not the message string), so APM tools (Datadog, Loki, Sentry) can group errors properly. Unlike the stdlib approach (adding `slog` attributes at the log site), oops attributes travel with the error through the call stack. ## Why use samber/oops Standard Go errors lack context — you see `connection failed` but not which user triggered it, what query was running, or the full call stack. `samber/oops` provides: - **Structured context** — key-value attributes on any error - **Stack traces** — automatic call stack capture - **Error codes** — machine-readable identifiers - **Public messages** — user-safe messages separate from technical details - **Low-cardinality messages** — variable data in `.With()` attributes, not the message string, so APM tools group errors properly This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform. ## Core pattern: Error builder chain All `oops` errors use a fluent builder pattern: ```