ez
errtrace
ez | errtrace | |
---|---|---|
2 | 4 | |
11 | 697 | |
- | 1.4% | |
2.7 | 8.6 | |
4 months ago | 2 days ago | |
Go | Go | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ez
-
Show HN: Error return traces for Go, inspired by Zig
While from a first instance, this package seems a bit overkill, I think the idea is interesting and is something that can be improved for Go.
I also felt that Go errors where too bare-bones, so I developed a small package (https://github.com/Vanclief/ez) based on an awesome post that I saw here once. I use this package in all Golang code I touch.
-
Go Replaces Interface{} with 'Any'
I used to really hate that. After reading this amazing post https://middlemost.com/failure-is-your-domain I created a module that makes this bearable https://github.com/Vanclief/ez
errtrace
- Error return traces for Go, inspired by Zig
-
Show HN: Error return traces for Go, inspired by Zig
The README covers the idea behind errtrace in more details, but the primary difference is in what is captured:
pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.
errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.
This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.
The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.
As an example, the [Try it out](https://github.com/bracesdev/errtrace/#try-it-out) section in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.
What are some alternatives?
errors - Simple error handling primitives
go - The Go programming language
rustic_result - Result monad for Elixir inspired by Rust Result type
go-formatter - A curated list of awesome Go frameworks, libraries and software
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
v2ray-core - A platform for building proxies to bypass network restrictions.
traefik - The Cloud Native Application Proxy