> 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
I 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.
And 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.
I 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.
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
then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 for that.