4 ms·

I was referring to how Bloch and Goetz have tried to tell Java devs for decades to avoid null, mutation and just in general the traditional Java coding style, w

by bedobi 2y ago

I was referring to how Bloch and Goetz have tried to tell Java devs for decades to avoid null, mutation and just in general the traditional Java coding style, with little success. As for exceptions, it's hilarious that they and the Java community in general are still stuck on arguing about checked vs unchecked exceptions. That's my whole point - you can argue about that forever and you will always be wrong, because exceptions are a failed experiment and will never work or reach a consensus. Move past it. I really, REALLY don't understand what's so wrong with just.. making methods return what they say they do, as plain objects. The antagonism towards doing so is literally just ingrained culture with zero sensible justification.

lolinder 2y ago
> I really, REALLY don't understand what's so wrong with just.. making methods return what they say they do, as plain objects. The antagonism towards doing so is literally just ingrained culture with zero sensible justification. From experience with Rust, a major concern is lack of stack traces in error messages. Rust has libraries that built up around Result to address this (like Anyhow), but by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types. For Rust this is probably more ergonomic than introducing exceptions into the language, but Java already has checked exceptions that work like Anyhow does out of the box. That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types, and they already exist and are widely used in the language. There are a few minor ergonomic problems that discourage their wider use, but it makes way more sense for Java to fix those than for people to migrate to Result types, which are not nearly as ergonomic in Java as they are in Rust or similar. You tried to address this upthread, but it was frankly a pretty bad strawman that contrasted a horrible example of checked exceptions with an idealized example of a Result type. You then compounded the strawman with a double standard by demanding that the checked exceptions example immediately account for what would happen in the catch block while hand-waving away the handling of Left values in the Result type as something that we can deal with at some unspecified later time. Dealing with failures later at the edges of the system is the reason why exceptions were invented, so it's highly disingenuous to claim that as a capability unique to Result types.
- ackfoobar 2y ago
  > by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types If the error is wrapped into an `anyhow::Error`, and the result in `anyhow::Result<T>`, it has less information than checked exceptions. Coz the type now only tells you the call can fail, but not how (it's anyhow!). > That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types That's the crux.

by bedobi 2y ago

lolinder 2y ago

> I really, REALLY don't understand what's so wrong with just.. making methods return what they say they do, as plain objects. The antagonism towards doing so is literally just ingrained culture with zero sensible justification. From experience with Rust, a major concern is lack of stack traces in error messages. Rust has libraries that built up around Result to address this (like Anyhow), but by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types. For Rust this is probably more ergonomic than introducing exceptions into the language, but Java already has checked exceptions that work like Anyhow does out of the box. That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types, and they already exist and are widely used in the language. There are a few minor ergonomic problems that discourage their wider use, but it makes way more sense for Java to fix those than for people to migrate to Result types, which are not nearly as ergonomic in Java as they are in Rust or similar. You tried to address this upthread, but it was frankly a pretty bad strawman that contrasted a horrible example of checked exceptions with an idealized example of a Result type. You then compounded the strawman with a double standard by demanding that the checked exceptions example immediately account for what would happen in the catch block while hand-waving away the handling of Left values in the Result type as something that we can deal with at some unspecified later time. Dealing with failures later at the edges of the system is the reason why exceptions were invented, so it's highly disingenuous to claim that as a capability unique to Result types.

ackfoobar 2y ago
> by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types If the error is wrapped into an `anyhow::Error`, and the result in `anyhow::Result<T>`, it has less information than checked exceptions. Coz the type now only tells you the call can fail, but not how (it's anyhow!). > That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types That's the crux.