3 ms·

My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on,

My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.

amenghra 3y ago
You could imagine a language which discourages bubbling exceptions by forcing you to catch and either handle or rethrow each possible exception -- while still making it hard to accidentally forget to handle an exception.
- jacobr1 3y ago
  Certainly, and go already comes pretty close that explicitness via returned errors. At that point, we are down to a style choice between exceptions and error returns. Honestly I'm not sure it matters and depends upon other factors being balanced in the ergonomics of the language. I don't see any reason why you couldn't accomplish the objective in either style of language. My point is that Go today, both as matter of language features and how it tends to be used via communal norms, incentivizes explicit error handling. The parent comment stated, "You are less likely to silently/accidentally drop an exception vs Go's tuple return values" and while I could easily imagine language features that discourage bubbling exceptions ... in practice, I think that tends to be more the norm than explicit handling of tuple returns.
- jcranmer 3y ago
  That's Java's checked exceptions...

amenghra 3y ago

You could imagine a language which discourages bubbling exceptions by forcing you to catch and either handle or rethrow each possible exception -- while still making it hard to accidentally forget to handle an exception.

jacobr1 3y ago
Certainly, and go already comes pretty close that explicitness via returned errors. At that point, we are down to a style choice between exceptions and error returns. Honestly I'm not sure it matters and depends upon other factors being balanced in the ergonomics of the language. I don't see any reason why you couldn't accomplish the objective in either style of language. My point is that Go today, both as matter of language features and how it tends to be used via communal norms, incentivizes explicit error handling. The parent comment stated, "You are less likely to silently/accidentally drop an exception vs Go's tuple return values" and while I could easily imagine language features that discourage bubbling exceptions ... in practice, I think that tends to be more the norm than explicit handling of tuple returns.
jcranmer 3y ago
That's Java's checked exceptions...