golang-error-handling

To wrap Go errors with context, use the %w verb in fmt.Errorf to preserve the original error chain. This allows downstream callers to unwrap and inspect errors using errors.Is and errors.As while maintaining the full context for production debugging.

The best way to handle multiple independent errors in golang is using errors.Join. This function combines multiple independent failures into a single error object, allowing you to aggregate and return them together without losing individual error details.

slog works with error handling by enforcing a single handling rule: either log the error OR return it, but never both. It uses low-cardinality log messages with variable data attached as structured attributes, which significantly reduces production log noise.

Use errors.Is to check if an error matches a specific sentinel error value, and use errors.As to extract a typed custom error from the chain. This distinction is critical for inspecting wrapped errors correctly across HTTP and service boundaries.

Yes, idiomatic Go error handling requires strict lowercase error strings. This standardizes error messages across creation, wrapping, and logging boundaries, ensuring consistency and preventing stylistic noise in production logs.

Use recover only at appropriate goroutine boundaries to prevent total service crashes from unexpected panics. You should avoid using panic for expected failures, relying instead on standard error returns for expected conditions.