Hacker News Reader

Comment by justinpombrio | Hacker News Reader

How do you deal with putting information in your error messages?

My understanding is that Zig errors can't contain any data. But an error message like "file not found" is awful. Are your error messages awful, or is there some way to get information into them so that you can say "file 'foo/bar.json' not found"?

View on HN

I personally replace it with logging. In most other languages, the common thing is to log error message up in the stack, where you actually handle the error in some way. In Zig, I do it whenever I trigger an error. I've only used Zig for one server application, so having a lot of error messages in logs works fine, even if some of them are possible redundant.

Zig runtime optionally records few last points in sources where the error is propagated to the caller so you get stack traces.

If you need more than that and error codes, then either log as the sibling suggested or use custom return types. Anything more complex than what can be encoded as error codes is not an exception.

In Go you can do errorf("%w: %s", err, path) so that you get "file not found: foo/bar.json", while still being able to match on the wrapped error value with errors.Is(). The caller can do the same with this error and so on up the stack

I dislike this style in Go. It adds a lot of noise to the source and essentially builds a stack trace manually. In Go 1.23 there is errors.Wrap() that adds the error stack automatically so maybe at some point Go will consider again adding some sugar for automatic error propagation.

Go errors in standard library does not support stack traces. errors.Wrap() only exists in github.com/pkg/errors package

Reply on news.ycombinator.com