Show HN: Error return traces for Go, inspired by Zig

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • errtrace

    An alternative to stack traces for your Go errors

    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.

  • errors

    Discontinued Simple error handling primitives

    Can you explain why we should this over https://github.com/pkg/errors?

  • 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.

  • ez

    Minimalistic package for handling Go errors in an easy way (by Vanclief)

    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.

  • zig

    General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

    https://github.com/ziglang/zig/issues/7295

    Or is it that the three years it’s been around indicate it will never progress?

  • golangci-lint

    Fast linters Runner for Go

    The "standard linter" in Go is https://golangci-lint.run/ , which includes [1] the absolutely-vital errcheck which will do that for you.

    For an Advent of Code challenge you may want to turn off a lot of other things, since the linter is broadly tuned for production, public code by default and you're creating burner code and don't care whether or not you have godoc comments for your functions, for instance. But I suggest using golangci-lint rather than errcheck directly because there's some other things you may find useful, like ineffassign, exportloopref, etc.

    [1]: https://golangci-lint.run/usage/linters/

  • 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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts