The implementation of WithMeta() is flawed. Not only is it not concurrency-safe, every nested call will be modifying the parent map.

The way to do this in a safe and performant manner is to structure the metadata as a tree, with a parent pointing to the previous metadata. You'd probably want to do some pooling and other optimizations to avoid allocating a map every time. Then all the maps can be immutable and therefore not require any locks. To construct the final map at error time, you simply traverse the map depth-first, building a merged map.

I'm not sure I agree with the approach, however. This system will incur a performance and memory penalty every time you descend into a new metadata context, even when no errors are occurring. Building up this contextual data (which presumably already exists on the call stack in the form of local variables) will be constantly going on and causing trouble in hot paths.

A better approach is to return a structured error describing the failed action that includes data known to the returner, which should have enough data to be meaningful. Then, every time you pass an error up the stack, you augment it with additional data so that everything can be gleaned from it. Rather than:

    val, err := GetStuff()
    if err != nil {
      return err
    }

    val, err := GetStuff()
    if err != nil {
      return fmt.Errorf("getting stuff: %w")
    }

    val, err := GetStuff()
    if err != nil {
      return wrapWithMetadata(err, meta.KV("database", db.Name))
    }

This pays the performance cost only at error time, and the contextual information travels up the stack with a tree of error causes that can be gotten with `errors.Unwrap()`. The point is that Go errors already are a tree of causes.

Sometimes tracking contextual information in a context is useful, of course. But I think the benefit of my approach is that a function returning an error only needs to provide what it knows about the failing error. Any "ambient" contextual information can be added by the caller at no extra cost when following the happy path.

These are good general tips applicable to other languages too. I strongly dislike when code returns errors as arbitrary strings rather than classes, as it makes errors extremely difficult to handle; one would presumably want to handle a http 502 diffrernetly to a 404, but if a programmer returns that in a string, I have to do some wonky regex instead of checking the type of error class (or pulling a property from an error class). I've commonly found JS and Go code particularly annoying as they tend to use strings, as the author mentioned.

An additional thing that is useful here would be a stack trace. So even when you catch, wrap & rethrow the error, you'll be able to see exactly where the error came from. The alternative is searching in the code for the string.

For the hate they seem to get, checked exceptions with error classes do give you a lot of stuff for free.

I wrote my own error wrapper: github.com/samber/oops

Example:

err := oops. Code("iam_missing_permission"). In("authz"). Tags("authz"). Time(time.Now()). With("user_id", 1234). With("permission", "post.create"). Hint("Runbook: https://doc.acme.org/doc/abcd.md"). User("user-123", "firstname", "john", "lastname", "doe"). Errorf("permission denied")

For easier debugging, the error contains the full stacktrace.

The `WithMeta` func will panic if not passed a multiple of 2 varargs. This is exactly what makes go error handling difficult in the first place. Imagine panicking in production because you passed a key without value to your error wrapper for some reason.

There are several existing Go error libraries with a similar approach sans context.

The approach I ended up taking is to use slog attributes. It allows for reuse of existing logging attributes.

This is explained here (skip to the “adding metadata” portion). https://blog.gregweber.info/blog/go-errors-library/

Go package: https://pkg.go.dev/github.com/gregwebs/errors/slogerr

Not a Go engineer but Go-curious - shouldn’t this use slog[0] for structured logging rather than a third party?

This is good stuff. After riding a unicorn and seeing systems mature over time as things change and scale grows, I've learned that Structured (Error) Logs are the only way to run systems at scale with sanity.

I wrote my Go version of this same error wrapping utility for the same reasons: https://github.com/sethgrid/kverr

My current work uses python and I am hoping to change us over to structured logs that play well with structured exceptions.

We've been storing values on errors using https://github.com/levenlabs/errctx for close to a decade now. We have a separate logging library that stores a KV map but technically you can store anything on errors. I recently just made it unwrap errors to find deeply stored keys.

One thing that seemingly is missing is the ability to tag a specific error with an error code. You typically want to know that all of a sudden the ”failed to get user” error is being returned a lot. Since the message is a dynamic string you can’t just group by the string so unless you build it as part of your abstraction it becomes very hard to do.

Edit: looking more carefully at the lib I assume that ”tag” is the concept that is supposed to cover this?

Alright, so this looks pretty comprehensive for error handling. But I gotta ask – for smaller to mid-size projects, is there a point where this level of structure becomes more work than it's worth?

i'm not sure the point here, you can carry along information in errors at API boundaries and collect the info when you emit a log line. Using built in errors.Wrapf and slog, you get everything you need already.

I wrote an article covering the same problems but with a slightly different solution a few years ago: https://alexrichey.com/articles/2021-09-09-error-handling-in...

This approach has been successful in major projects at work and on the side for several years now.

Yeah always thought error handling is a bit wonky in Go. (Un)fortunately, most of my tinkering with Go are just toy level scripts. Thanks for the write up, will check the library!

[dead]

[dead]