Simple error handling primitives
8.3k
Stars
714
Forks
44
Open issues
30
Contributors
AI Analysis
pkg/errors provides Go error-handling primitives that add context to errors while preserving the original error value, solving the problem of context-less error reports in Go's traditional error handling. It is purpose-built for Go developers who need structured error wrapping and cause inspection, and is not relevant for other languages or developers using Go 1.20+ where error wrapping is now built-in to the standard library.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
pkg/errors: The Go error-wrapping library that shaped stdlib, now in maintenance
pkg/errors solves the problem of context-free error propagation in Go by providing Wrap, Cause, and stack-trace primitives. It was built for Go developers who needed structured, debuggable errors before Go 1.13 added %w and errors.Is/As to the standard library. It saw massive adoption across the Go ecosystem and directly influenced how Go 2 error proposals were shaped. Today it is explicitly in maintenance mode—no new features, only bug fixes—but remains widely depended upon as a transitive dependency in countless projects.
Created in December 2015 by Dave Cheney to address a well-known pain point in Go's error model. It became a de facto standard until Go 1.13 (2019) introduced native error wrapping, at which point the project voluntarily entered maintenance mode.
Growth was rapid from 2015–2019, driven by community consensus that Go's native errors were insufficient. The project peaked as Go's most-referenced third-party error package. After Go 1.13, new adoption slowed sharply as stdlib absorbed the core ideas. Current star velocity (~2/week) reflects legacy reference traffic, not active new adoption.
Extremely well-documented in production: pkg/errors is a transitive dependency in thousands of Go modules indexed on pkg.go.dev, including major projects like Docker, Kubernetes tooling, and countless microservice frameworks. Its influence on the Go stdlib error model is itself evidence of industry-level validation.
Appears to be a small, focused package with a thin API surface: Wrap, Cause, New, Errorf, and stack-trace types. Likely uses interface composition (the 'causer' interface) to chain errors without losing original values. No external dependencies based on the package's minimalist design philosophy.
Not documented in README, but CI badges (Travis-CI, AppVeyor) are present, suggesting automated test runs exist. Actual coverage percentage is not stated.
Last push was March 2026 (~3 months before current date), which indicates the repository is still receiving occasional updates. The README explicitly declares maintenance mode, so low commit frequency is intentional policy, not neglect. This is slow-by-design, not stagnant.
ADOPT IF: you are maintaining existing code that already depends on pkg/errors and migration cost outweighs benefits, or you specifically need stack traces in a Go project and want a battle-tested, stable API. AVOID IF: you are starting a new Go project—prefer stdlib errors with %w plus cockroachdb/errors if stack traces are needed. MONITOR IF: you have deep transitive dependencies on pkg/errors and want to track whether a final 1.0 release clarifies the long-term support posture.
Independent dimensions
Mainstream potential
2/10
Technical importance
8/10
Adoption evidence
9/10
- Officially in maintenance mode: no new features will be added, and the project may eventually be archived.
- The stack trace implementation pre-dates Go module conventions and may have subtle incompatibilities with newer Go runtime internals over time.
- Cause() is not compatible with stdlib errors.Is/As unwrapping without explicit bridging code, creating interoperability friction in mixed codebases.
- CI configuration references Travis-CI, which has had reliability issues; test infrastructure may be partially degraded without being visible in metadata.
- Developer mindshare has shifted to stdlib patterns; new Go developers may be unfamiliar with the Cause/Wrap API, increasing onboarding friction.
pkg/errors will remain stable and available as a dependency for legacy codebases for years, but will see negligible new adoption. A formal 1.0 release remains pending per the README roadmap.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Go
- License
- BSD-2-Clause
- Last updated
- 3mo ago
- Created
- 128mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Top contributors
Similar repos
hashicorp/go-multierror
go-multierror is a Go library for aggregating multiple errors into a single...
ehmicky/modern-errors
Modern-errors is a JavaScript library for creating, handling, and normalizing...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
8.3k | +1 | Go | 8/10 | 3mo ago |
|
|
2.4k | — | Go | 8/10 | 7d ago |
|
|
2.6k | — | Go | 8/10 | 4d ago |
|
|
1.5k | — | JavaScript | 8/10 | 2w ago |
|
|
3k | — | Go | 8/10 | 1w ago |
|
|
20.1k | — | Go | 9/10 | 7d ago |
The stdlib now provides %w wrapping, errors.Is, and errors.As, covering the most common use cases. It does NOT provide stack traces, which remains pkg/errors' sole remaining differentiator. New projects should prefer stdlib unless stack traces are required.
A more fully-featured drop-in replacement that adds stack traces, error domains, PII-safe reporting, and stdlib compatibility. Better choice for new projects that need what pkg/errors offered plus more. More complex and heavyweight.
An experimental package that prototyped the error API eventually merged into Go 1.13 stdlib. Largely superseded by stdlib now, similar lifecycle to pkg/errors.
Solves a different problem—aggregating multiple errors—rather than wrapping and stack tracing. Not a direct competitor but often used alongside error wrapping libraries.
A smaller alternative also focused on stack traces. Less adopted and less influential than pkg/errors, but still active. Serves the same niche for new projects wanting stack traces without pkg/errors' maintenance-mode status.