3 ms·

That's not the reason to remove checked exceptions from Java. The reason is that exceptions don't compose - they don't play well with functional style code whic

That's not the reason to remove checked exceptions from Java. The reason is that exceptions don't compose - they don't play well with functional style code which otherwise works pretty well in Java.

Groxx 3y ago
Yeah. Checked exceptions are fine - it's just an early returning version of error/result-ADTs (which are widely used and loved). Java's implementation isn't generic over exception types, so you're forced to make Bad Decisions constantly.
- PhilipRoman 3y ago
  Fun fact: you can actually parameterize functions and types over exception types in Java, <T extends Throwable> ... throws T will type check as expected. Of course, if you solve a problem using generics, you will now have 2 problems instead of 1...
  - Thiez 3y ago
    And stuff like the Stream api does not use these generics, so you end up wrapping exceptions in RuntimeException anyway, which... again defeats the point of checked exceptions.
  - Groxx 3y ago
    I have never tried that, thanks! Does it work for a variable list of things, or would supporting two different checked exceptions require two generic params? If it's one per param I think that's neat but probably limited in use to "your exception can contain a generic value", like `throw NewInsertFailedException(value)`.
    - PhilipRoman 3y ago
      I think you might be able to trick the type checker to accept union types, but I'm not sure. I know intersection types are possible, but they are not really useful for exceptions. Regarding practicality - I've used this feature when implementing a visitor class API, so it definitely has some use cases. The biggest problem is that all it takes is a single method in the chain which does not support this pattern (think java.util.stream). For internal code it's pretty easy to decorate all functions that take callback lambdas, etc.

3 ms·

That's not the reason to remove checked exceptions from Java. The reason is that exceptions don't compose - they don't play well with functional style code whic

by speed_spread 3y ago

That's not the reason to remove checked exceptions from Java. The reason is that exceptions don't compose - they don't play well with functional style code which otherwise works pretty well in Java.

Groxx 3y ago
Yeah. Checked exceptions are fine - it's just an early returning version of error/result-ADTs (which are widely used and loved). Java's implementation isn't generic over exception types, so you're forced to make Bad Decisions constantly.
- PhilipRoman 3y ago
  Fun fact: you can actually parameterize functions and types over exception types in Java, <T extends Throwable> ... throws T will type check as expected. Of course, if you solve a problem using generics, you will now have 2 problems instead of 1...
  - Thiez 3y ago
    And stuff like the Stream api does not use these generics, so you end up wrapping exceptions in RuntimeException anyway, which... again defeats the point of checked exceptions.
  - Groxx 3y ago
    I have never tried that, thanks! Does it work for a variable list of things, or would supporting two different checked exceptions require two generic params? If it's one per param I think that's neat but probably limited in use to "your exception can contain a generic value", like `throw NewInsertFailedException(value)`.
    - PhilipRoman 3y ago
      I think you might be able to trick the type checker to accept union types, but I'm not sure. I know intersection types are possible, but they are not really useful for exceptions. Regarding practicality - I've used this feature when implementing a visitor class API, so it definitely has some use cases. The biggest problem is that all it takes is a single method in the chain which does not support this pattern (think java.util.stream). For internal code it's pretty easy to decorate all functions that take callback lambdas, etc.