SaaSHub helps you find the best software and product alternatives Learn more →
Top 17 Go Error Projects
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
slog-multi
🚨 Design workflows of slog handlers: pipeline, middleware, fanout, routing, failover, load balancing...
-
doctorgpt
DoctorGPT brings GPT into production for application log error diagnosing! (by ingyamilmolinar)
-
oops
🔥 Error handling library with context, assertion, stack trace and source fragments (by samber)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
errors
A simple error library that supports error stacks, error codes, and error chains. (by morrisxyang)
-
problem-details
ProblemDetails is a Error Handler base on [RFC 7807] standard to map our error to standardized error payload to client.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
In our codebase I noticed a few cases where people ignored errors returned from functions by assigning them to _, ie result, _ := foo(). The errcheck linter doesn't seem to catch this, does anyone know of a linter that does?
This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!?
Have you seen https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics.
But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.
Project mention: A simple friendly error library that supports error codes, error stacks, and error chains. | /r/golang | 2023-07-10
Project mention: All you need is Wide Events, not "Metrics, Logs and Traces" | news.ycombinator.com | 2024-02-27There seems to be somebody trying to do the second idea for Go's slog package: https://github.com/samber/slog-parquet
Go Error related posts
- Linter to check for errors ignored with _
- Integration Tests failing
- ProblemDetails: Error Handler base on RFC 7807 standard for Go.
- ProblemDetails: Error Handler base on RFC 7807 standard for Go.
- ProblemDetails: it's an Error Handler base on RFC 7807 standard to map our error to standardized error payload to client.
- Uhoh
- Wrapcheck v2.3.0 released: Ignore package signatures
-
A note from our sponsor - SaaSHub
www.saashub.com | 26 Apr 2024
Index
What are some of the best open-source Error projects in Go? This list will help you:
Project | Stars | |
---|---|---|
1 | errcheck | 2,281 |
2 | emperror | 327 |
3 | wrapcheck | 279 |
4 | slog-multi | 243 |
5 | doctorgpt | 196 |
6 | oops | 167 |
7 | slog-formatter | 85 |
8 | slog-gin | 71 |
9 | errors | 55 |
10 | err2 | 49 |
11 | problem-details | 47 |
12 | slog-sentry | 31 |
13 | valor | 16 |
14 | slog-parquet | 9 |
15 | slog-datadog | 7 |
16 | uhoh | 4 |
17 | errdetail | 2 |
Sponsored