go-error-handling

Wrap errors with context using fmt.Errorf with the %w verb: fmt.Errorf("operation failed: %w", err). This preserves the original error for inspection with errors.Is and errors.As while adding descriptive context at each function boundary.

Sentinel errors are predefined error values you compare against using errors.Is to signal specific failure modes. Define them as package-level variables (e.g., var ErrNotFound = errors.New("not found")) to enable callers to handle particular error types without parsing error messages.

Define a custom type implementing the error interface by providing an Error() string method. Include fields for context data, then create instances with all relevant information so callers can extract details using errors.As for type assertion and field access.

Use errors.Is to compare against sentinel errors and errors.As to extract custom error types by their struct type. Both functions unwrap error chains automatically, so they work with wrapped errors returned from nested function calls.

Reserve panic and recover for truly unrecoverable conditions or programming errors, not expected failures. Most application errors should return error values; panic/recover is appropriate for invariant violations or initialization failures that leave the program in an invalid state.

Go's errors package doesn't provide built-in multi-error support, but you can implement a custom error type holding a slice of errors, or use third-party multi-error packages. Return this collection when multiple independent failures occur, then iterate or aggregate them for reporting.