Errors Alternatives
Similar projects and alternatives to errors
-
-
-
SonarLint
Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.
-
-
-
Testify
A toolkit with common assertions and mocks that plays nicely with the standard library
-
-
go-multierror
A Go (golang) package for representing a list of errors as a single error.
-
Scout APM
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
-
-
-
Gin
Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
-
-
-
-
-
-
-
-
-
-
errors reviews and mentions
-
My next client wants to redevelop a java Webapp with go
pkg/errors or stdlib errors - Error handling, but I wrote my own package for that tailored to my projects' needs. (FYI primalskill/errors but please don't use it as it's not production-ready yet and it will change a lot)
-
Wrapping Errors in Go - How to Handle Nested Errors
They should probably only mention them to say that they are not compatible with stdlib error wrapping and you should probably never use them in any new code. If you have to write new code that uses the stdlib wrapping and interacts with old code that uses github.com/pkg/errors then you'll probably need a wrapper for pkg/error wrapped errors so they can be inspected by the stdlib functions.
-
What are some good open source project to read when learning Go?
https://github.com/pkg/errors - errors with stack traces
-
Anyone using github.com/pkg/errors for stack traces?
The pkg.go.dev page lists 14k+ projects importing it, but the Github repository has been archived which would seem to discourage use. I'm also not a huge fan of the naming conflict with the stdlib errors package. The README notes it went into maintenance mode but it appears this, too, has passed.
-
go-faster/errors: clear go error wrapping with caller (xerrors fork with Wrap)
The pkg/errors and xerrrors are not maintainted
-
Errors and Error Wrapping in Go
This is nice, but what I miss is that that there are more ways, for example by using this package: https://github.com/pkg/errors You can pass errors almost the same, and in the end have a stack-trace for free :-) (And I personally really like that a lot)
-
Go Replaces Interface{} with 'Any'
Stack trace was part of a proposal to add to the error package but it didn't happen. You can use third party errors packages like https://github.com/pkg/errors which wrap errors with stack traces.
-
What are the cool kids learning these days?
But that's not even my complaint about golang errors. As always with this language, the execution sucks. It's bizarre is that a language so focused on strong standards doesn't provide a sufficient error handling model in the stdlib. The community more or less decided on this 3rd party library https://github.com/pkg/errors, but the stdlib recently added it's own methods. Neither are sufficient. Some libraries use opaque errors, others make an interface, others panic() to represent the same error. Some use the old stdlib, some use the new stdlib, some use pkg/errors, some make their own implementation. Every library is doing errors differently and it's a total mess.
-
Custom error capable of wrapping another error?
github.com/pkg/errors you can wrap your errors like this perhaps: ``` if err != nil { return errors.Wrap(err, "a message of your choice") } ```
- Github.com/pkg/errors just got archived, I made a maintained v2 with many fixes
-
Uhoh
I think "github.com/pkg/errors" does this quite good actually.
-
Go: Don't Change the Libraries in 1.18
I think they've been worse about this w.r.t. tooling (dep comes to mind. The closest thing I can think of along this path for the standard library would be how they've handled errors, and deciding to go their own way instead of adopting dave cheney's pkg/errors[0]
they do definitely seem to have some NIH syndrome at times, but I can't say that as time has progressed that I haven't come to appreciate the decisions they've made that seemed controversial at the time.
- Three Things Go Needs More Than Generics
-
Error handling seems to be a recurring theme in go, but most proposals get nowhere
Check this out: https://github.com/pkg/errors . There are also many other packages that do something similar, with varying degrees of fanciness in how they output the stack trace.
- Pkg/errors is looking for new maintainers
Stats
pkg/errors is an open source project licensed under BSD 2-clause "Simplified" License which is an OSI approved license.
Popular Comparisons
Are you hiring? Post a new remote job listing for free.