golang-samber-oops

Implements structured error handling in Go using the samber/oops builder pattern.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/santoshkal/chezmoi --skill golang-samber-oops-santoshkal
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-samber-oops
Source: https://github.com/santoshkal/chezmoi/tree/main/private_dot_config/opencode/skills/Golang/skills/golang-samber-oops
Command: npx skills add https://github.com/santoshkal/chezmoi --skill golang-samber-oops-santoshkal

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires github.com/samber/oops, and includes references (resource) components.

What problem does it solve? Standard Go errors lack context — you see "connection failed" but not which user triggered it, what query was running, or the full call stack. This Skill guides AI coding agents to write structured, diagnosable error handling with samber/oops so on-call engineers can diagnose failures without asking the developer. ## Core Features & Use Cases - Fluent error builders: Chain .In(), .Tags(), .Code(), .With(), .User(), and .Tenant() to attach domain, categorization, and structured attributes to every error. - Layered wrapping and panic recovery: Wrap errors at each architectural boundary with Wrapf, and convert panics to structured errors with oops.Recover at goroutine boundaries. - Public vs technical messages: Separate user-safe messages via .Public() from technical details, and retrieve them with oops.GetPublic for HTTP responses. - Use Case: In a multi-tenant SaaS API, build errors that carry tenant plan, user email, trace IDs, and low-cardinality messages so Datadog or Sentry can group and alert on them correctly. ## Quick Start Ask the agent to refactor your Go service's error handling to use samber/oops with structured attributes, error codes, and layered wrapping.

Frequently Asked Questions about golang-samber-oops

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

FAQPage Schema
How do I add structured context to Go errors with samber/oops?▼

Use the fluent builder pattern: chain .In() for the domain, .With() for key-value attributes, .Code() for a machine-readable identifier, then terminate with .Errorf() or .Wrapf(). Variable data goes in .With() attributes, not the message string, so APM tools can group errors.

samber/oops vs standard Go errors: what is the difference?▼

Standard Go errors carry only a message string, while samber/oops adds structured attributes, stack traces, error codes, tags, and public messages that travel with the error through the call stack. It is a drop-in replacement since OopsError implements the standard error interface.

Do I need a nil check before calling oops.Wrap or Wrapf?▼

No. oops.Wrap and oops.Wrapf return nil when the input error is nil, so you can write return oops.Wrapf(err, "operation failed") directly without an if err != nil block.

How do I convert panics to errors in Go goroutines?▼

Use oops.Recover or the builder's .Recover() method at goroutine boundaries, passing the risky operation as a function. Use a named error return value so Recover can set it, and add context like .In() and .Code() to the recovery builder.

How do I show user-friendly messages while logging technical details?▼

Set a user-safe message with .Public() and keep technical details in .Errorf() or .Wrapf(). At the HTTP layer, retrieve the safe message with oops.GetPublic(err, "fallback") and log the full error with its attributes separately.

How do I configure samber/oops stack trace depth and timezone?▼

Set the global variables oops.StackTraceMaxDepth for trace depth, oops.Local with time.LoadLocation for timestamp timezone, and oops.SourceFragmentsHidden to disable source code fragments. No wrapper or post-processing is needed.