samber-oops

Wrap Go errors with stack traces, codes, and key-value attributes using samber/oops.

1|2|Updated Nov 25, 2017
One-click install
npx skills add https://github.com/asarchami/dotfiles --skill samber-oops-asarchami
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: samber-oops
Source: https://github.com/asarchami/dotfiles/tree/main/dot_config/opencode/skills/samber/samber-oops
Command: npx skills add https://github.com/asarchami/dotfiles --skill samber-oops-asarchami

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Go errors often lose context as they travel up the call stack, leaving on-call engineers without the domain, attributes, or trace IDs needed to diagnose failures. This Skill guides structured error wrapping with samber/oops so every error carries enough context for diagnosis and groups correctly in APM tools like Datadog, Loki, and Sentry. ## Core Features & Use Cases - Layer-boundary wrapping: Wrap errors at each package boundary with .Wrapf, attaching the context that layer knows via .With, .In, .Tags, and .Code. - Low-cardinality messages: Keep error messages static and move runtime values (user IDs, queries, tenants) into attributes so APM tools group errors correctly. - Panic recovery and enrichment: Convert panics to structured errors with .Recover at goroutine boundaries, and attach HTTP requests, identity, and trace context with .Request, .User, and .Trace. - Use Case: While reviewing a Go service, you find handlers returning bare fmt.Errorf results. Use this Skill to rewrite each layer to wrap errors with domain, code, and attributes, then read back Code/Stacktrace at the top for logging and public messages. ## Quick Start Ask the AI to refactor your Go error handling to wrap errors with samber/oops, adding domain, code, and attributes at each layer boundary.

Frequently Asked Questions about samber-oops

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

FAQPage Schema
How do I wrap errors with context in Go using samber/oops?

Use the fluent builder: start with oops.In("domain"), add attributes with .With("key", value), and finish with .Wrapf(err, "operation failed") for existing errors or .Errorf for new ones. Wrap once at each layer boundary so every layer adds the context it knows.

How do I add attributes like user ID or trace ID to a Go error?

Attach them with builder methods: .With("user_id", id) for custom key-values, .User(id) for identity, .Tenant(id) for organization context, and .Trace(id) for correlation IDs. Keep these out of the message string so APM grouping stays stable.

Does samber/oops work with slog and other loggers?

Yes, oops errors integrate with any logger. Use slog.Error(err.Error(), slog.Any("error", err)) for slog, or type-assert to oops.OopsError to extract Code, Domain, Tags, Context, and Stacktrace for structured log fields. JSON marshaling is also supported.

How do I recover panics as structured errors in Go goroutines?

Call .Recover(fn) at the goroutine or handler boundary to convert a panic into a structured oops error. Add .Code("panic_recovered") and .Hint(...) so the recovery is actionable for the on-call engineer.

Why should error messages avoid interpolating user IDs?

Interpolating runtime values into messages creates high-cardinality strings that break error grouping in Datadog, Loki, and Sentry. Keep the message static and put variable data in .With() attributes instead.

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

No, oops.Wrap and .Wrapf return nil when given a nil error, so you can return oops.Wrapf(err, "...") directly. Guarding it with if err != nil is redundant.