Tracing errors in Go using custom error types.
While I had previously sworn off writing more about errors in Go, it might help to share one of my strategies for making Go error handling more informational.
Firstly, I am sharing my overarching position; the Go language choice of explicit error handling at the point of error is straightforward and makes for unambiguous implementations and easy-to-reason code, even when you return months later to a code base. Conversely, handling an error at a distance’ exception style’ can lead to deceptively more straightforward-looking code that hides harder-to-debug errors and, unfortunately, can result in exceptions as flow control.
There are issues with Go’s errors, though; the problems occur when an error is received and passed through a relatively long call chain. We need to answer the question, where did the error come from, and how do I set a breakpoint in my debugger to break at the error? Exceptions provide this for free.
I’ve been prototyping some reasonably complex transactional ledger-related code over the past few months where I wish to roll back the…
