3 ms·
> A pragmatic “handle it here or bubble it up” is a much better approach This is exactly the approach used in Go code, so I'm not sure what you're referring to
by smasher164 4y ago
> A pragmatic “handle it here or bubble it up” is a much better approach
This is exactly the approach used in Go code, so I'm not sure what you're referring to. If you're talking about the fact that you can technically ignore an error result like
res, _ := doWork()
then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 https://staticcheck.io/docs/checks#SA4006 for that.
- kaba0 4y agoI don’t see any automatic bubble up with Go.
- smasher164 4y agoI don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler. Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.
- kaba0 4y agoAnd that is exactly the wrong approach. You really can’t do anything with the error case at most places. If I write a web server, which parts could knowingly handle a db connection error? Either the db driver internally, or going 10 deep higher and the request handler returning an 500 error. In go you would just verbosely (and error pronely!!) have to manually bubble it up, while this is automatically happening in Java with an informative stack trace, with no option to forget about it. Java is the one that handles error cases properly (and that’s why you might see exceptions more there — because they weren’t silenced somewhere wrongly!) here.
- smasher164 4y agoI agree that a stack trace is useful, but I disagree that automatic bubbling is universally good. If you look at well-written Go, context is added to every site where you bubble up an error.