4 ms·
The problem (as alluded to above) is that stacktraces give you no context to what went wrong, only where it happened and the (possibly cryptic) underlying error
by kitd 3y ago
The problem (as alluded to above) is that stacktraces give you no context to what went wrong, only where it happened and the (possibly cryptic) underlying error.
IMO the real value in proper error handling (ie what makes fixing errors easy) is that context, not the precise line # of the error which, though useful, is supplementary data. Rust errors with anyhow::Contexts are far more workable than those without.
Edit: I actually wrote a simple Result handling package for Go that includes error context and stacktraces: https://github.com/kitd/chock https://github.com/kitd/chock
- kaba0 3y agoThat’s why you throw an exception, catch it some level up, and rethrow it wrapped in another exception, with proper context.
- kitd 3y agoI think we're arriving at the same solution, with approximately the same amount of boilerplate if done to same degree of accuracy.
- marcus_holmes 3y agoExcept no-one does this in practice. There's a half-assed exception handler at the top level that catches everything and that's all. At least in most of the code bases I've seen. Go encourages you to handle the error at the point of calling, which is good.
- kaba0 3y agoIt’s still better than swallowing an error.
- lmm 3y agoBut in practice people don't do that in Go either, they just add a bunch of if error != nil lines, so you end up with no more information about what went wrong (in fact less information than you'd get with an exception, since you don't even get a stack trace) and just have more clutter in your code.
- kitd 3y agoIt's not the `if err != nil` that's the problem, it's the following `return nil`. As I mention above, return instead the error with some identifying information and context, and you get highly targeted details needed to locate and fix the problem. And the way Go handles this makes it simpler than doing it via exception handling.