3 ms·
That’s why you throw an exception, catch it some level up, and rethrow it wrapped in another exception, with proper context.
by kaba0 3y ago
That’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.