If done comprehensively, this strategy has the potential to be much better than a traditional stacktrace because you can embed local variables within each additional error context string.
The main problem with traditional stacktraces is that, while you get line numbers, local variables at every stack frame are not preserved. So unless the error is obvious like FileNotFound, you’re left guessing as to how the error happened.
While still being hella verbose and probably too much effort for most code, the upfront investment would obviate the need for adding debug print statements or dropping into a breakpoint to inspect the code after an exception.
That said, the post does feel like copium for the ridiculous verbosity in Go and re-inventing chained exceptions.
The main problem with traditional stacktraces is that, while you get line numbers, local variables at every stack frame are not preserved. So unless the error is obvious like FileNotFound, you’re left guessing as to how the error happened.
While still being hella verbose and probably too much effort for most code, the upfront investment would obviate the need for adding debug print statements or dropping into a breakpoint to inspect the code after an exception.
That said, the post does feel like copium for the ridiculous verbosity in Go and re-inventing chained exceptions.