3 ms·

> This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, wri

> This is a deliberate decision to ignore the error - the programmer needed to explicitly type this out. As such, it's not a problem at all. Even if it was, writing a linter to detect it would be trivial. So is not handling Java exceptions is deliberate, and again, Java forces you to handle managed exceptions. > While it's nice that uncaught exceptions stop the program from continuing with invalid state, it'd be strictly better to not have them in the first place. That's what languages with explicit error returns provide - can't have uncaught errors if you're forced to explicitly deal with every possible error. The resulting software is way more robust that way. Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Furthermore, Go has (stupid) exceptions, it's called panics.

Mawr 5y ago
> So is not handling Java exceptions is deliberate That's the thing, there's no visible difference between a deliberately ignored exception and a purposefully ignored one. The code looks exactly the same: foo() Did I purposefully ignore the exception or not? Can `foo()` even throw an exception? There's no way to know. Once you've programmed with explicit error returns, coming back to exceptions is unnerving. Anything may or may not throw at any time and there's no way to know. > Java forces you to handle managed exceptions. I'm referring to the far more common unchecked exceptions. Java's checked exceptions are a whole another bag of demons I don't want to get into right now. > Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Thing is, conventions matter. A lot. The proof is in the pudding: - what's the ratio of exception-based Java code to error-based Java code? - what's the ratio of error-based Go code to exception-based Go code? Somehow both ratios end up close to 100%, despite neither language forcing their users to use a specific error handling method. That's because there's space between forcing something and completely ignoring it. I often call it "nudging". Languages often do, and should, nudge their programmers into certain ways of programming that fit their philosophy. > Furthermore, Go has (stupid) exceptions, it's called panics. I assume by "stupid" you mean that panics are underfeatured compared to "real" exceptions. That's intended, you're not supposed to catch panics in the first place. They're only there to address runtime issues that are almost always unrecoverable: running out of memory, out-of-bounds array access, regex compilation failure, etc.

Mawr 5y ago

> So is not handling Java exceptions is deliberate That's the thing, there's no visible difference between a deliberately ignored exception and a purposefully ignored one. The code looks exactly the same: foo() Did I purposefully ignore the exception or not? Can `foo()` even throw an exception? There's no way to know. Once you've programmed with explicit error returns, coming back to exceptions is unnerving. Anything may or may not throw at any time and there's no way to know. > Java forces you to handle managed exceptions. I'm referring to the far more common unchecked exceptions. Java's checked exceptions are a whole another bag of demons I don't want to get into right now. > Errors as value in Go are purely a convention, nothing precludes you from doing the exact same thing in Java, or JavaScript or any other possible language that has exceptions. Thing is, conventions matter. A lot. The proof is in the pudding: - what's the ratio of exception-based Java code to error-based Java code? - what's the ratio of error-based Go code to exception-based Go code? Somehow both ratios end up close to 100%, despite neither language forcing their users to use a specific error handling method. That's because there's space between forcing something and completely ignoring it. I often call it "nudging". Languages often do, and should, nudge their programmers into certain ways of programming that fit their philosophy. > Furthermore, Go has (stupid) exceptions, it's called panics. I assume by "stupid" you mean that panics are underfeatured compared to "real" exceptions. That's intended, you're not supposed to catch panics in the first place. They're only there to address runtime issues that are almost always unrecoverable: running out of memory, out-of-bounds array access, regex compilation failure, etc.