3 ms·

Agree, wrapping errors continues to build context until you have a clear trail of blame for the issue. Most languages just expect you to read the stack trace a

Agree, wrapping errors continues to build context until you have a clear trail of blame for the issue. Most languages just expect you to read the stack trace and figure it out. Proper error handling tells you explicitly how it failed at each level so you can decide what to do at each level of the codebase. Having global try/catch (or bang as the author suggests) is easier at first, but makes actually handling error paths worse.

Xeoncross 3y ago
Here is an fictitious example of an error that was wrapped from deep in the internals of the net package all the way up to the HTTP handler serving the user. It was wrapped five times and clearly outlines what went wrong at each stage. > failed loading config: unable to reach host example.com: tcp: dns lookup: timeout https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is and friends can be used to figure out what type/class of error exists in this chain so there is no loss of information either. It's more than just string concatenation. It's an actual tree of errors that also presents well for the logger.
Cthulhu_ 3y ago
And the stack trace comes with its own issue; they are expensive. Which is fine, if the exception is actually true to the name - an exceptional situation. But in practice / production, exceptions / errors are not exceptional. Take a HTTP server. Due to a myriad of reasons, the connection between the server and a client can be severed, triggering an error because the connection was broken. Is that exceptional? No, the internet is unstable and clients are unreliable. Is it therefore valuable to generate a stack trace every time that happens? One exception is fine, but if you go web scale like Google, the "this connection was interrupted" case happens millions of times a day. Millions of times the cost of generating an exception + stack trace becomes really expensive. An error is cheap in comparison.

Xeoncross 3y ago

Here is an fictitious example of an error that was wrapped from deep in the internals of the net package all the way up to the HTTP handler serving the user. It was wrapped five times and clearly outlines what went wrong at each stage. > failed loading config: unable to reach host example.com: tcp: dns lookup: timeout https://pkg.go.dev/errors#Is https://pkg.go.dev/errors#Is and friends can be used to figure out what type/class of error exists in this chain so there is no loss of information either. It's more than just string concatenation. It's an actual tree of errors that also presents well for the logger.

Cthulhu_ 3y ago

And the stack trace comes with its own issue; they are expensive. Which is fine, if the exception is actually true to the name - an exceptional situation. But in practice / production, exceptions / errors are not exceptional. Take a HTTP server. Due to a myriad of reasons, the connection between the server and a client can be severed, triggering an error because the connection was broken. Is that exceptional? No, the internet is unstable and clients are unreliable. Is it therefore valuable to generate a stack trace every time that happens? One exception is fine, but if you go web scale like Google, the "this connection was interrupted" case happens millions of times a day. Millions of times the cost of generating an exception + stack trace becomes really expensive. An error is cheap in comparison.