6 ms·

Java has/had a compiler check that forced you to write catch blocks or `throws` annotations in/on functions that call other functions which might throw. The fe

Java has/had a compiler check that forced you to write catch blocks or `throws` annotations in/on functions that call other functions which might throw. The feature is called "checked exceptions" and I believe it has been discarded for its inconvenience by now. Sometimes it feels like developers are going in circles while trying to find the most optimal way to handle errors.

brabel 3y ago
People are now realizing that having the errors a function can cause right in the type system may actually have been a good idea, but when you point out that Result is not the only way and that Java checked Exceptions do the exact same thing (and so does the Zig error handling mechanism which is a third variant of the idea), they come up with all sorts of easily dismissable nonsense to explain why the two are very different.
- oblio 3y ago
  What would you reply to this comment: https://news.ycombinator.com/item?id=37174698 https://news.ycombinator.com/item?id=37174698
  - layer8 3y ago
    I’m not the parent, but exception declarations are IMO necessary for a stable API contract. It’s exactly the same reason why return types are explicit. The actual issue in Java is that you can’t abstract over an arbitrary-length list (sum) of checked-exception types (variadic type parameters) (with the exception of rethrowing from multi-catch clauses).
  - brabel 3y ago
    Well, that's kind of true! The fact checked Exceptions are inconvenient doesn't change the fact they are equivalent to returning a Result type (the implementation is obviously different but I think we don't need to mention that). A future version of Java could totally make it more convenient, and perhaps even make the implementation cheaper such that it would not just nearly the same , but literally the same as in Rust or other similar languages.
    - piaste 3y ago
      Does it even need a new language version? If the compiler already spits out the error "hey, your Fart() function should be annotated with 'throws ButtsException'", couldn't an IDE relatively easily be configured to automatically add the " throws " annotations?
      - brabel 3y ago
        Have you ever used Java?? Any half decent IDE has done that since 2000.
        piaste 3y ago
        Never in anger - I've done some JVM coding, but always in Kotlin (which doesn't have checked exceptions). If Java IDEs have been able to automatically take care of checked exceptions forever, then why do people say that they're inconvenient?
        brabel 3y ago
        Because the people saying that usually do not program in Java.
layer8 3y ago
Checked exceptions are one of the main reasons I’m sticking with Java, even though Java lacks the ability to abstract over sets of checked exceptions, which does cause some inconvenience. It’s unfortunate that no other mainstream languages have been taking that approach.
- 1-more 3y ago
  That sounds awesome! Do you have that flag set on a big codebase? Was it a big hassle to turn it on (like you had to remediate a bunch of code that didn't handle exceptions before you could check it in). Have you seen any big changes since enabling it?
  - gbear605 3y ago
    Checked exceptions in Java are the default state and much of the standard library uses them.
- wizzwizz4 3y ago
  In languages with a Result type (or Either monad), you basically do have checked exceptions, even though the language has no exceptions.
  - ivolimmen 3y ago
    Java also has that option. There is an excellent library called vavr. It adds the Try and Either monad to Java.
  - layer8 3y ago
    With result types, you typically don’t get automatic exception propagation. I agree that overall it’s a spectrum of syntactic convenience, checked exceptions effectively form a sum type together with the regular return type.
thuridas 3y ago
After working with railway oriented programming with Arrow in Kotlin I had the same feeling of using checked exceptions. And please make the Errors generically wrappable in order to avoid losing the traces.

brabel 3y ago

People are now realizing that having the errors a function can cause right in the type system may actually have been a good idea, but when you point out that Result is not the only way and that Java checked Exceptions do the exact same thing (and so does the Zig error handling mechanism which is a third variant of the idea), they come up with all sorts of easily dismissable nonsense to explain why the two are very different.

oblio 3y ago
What would you reply to this comment: https://news.ycombinator.com/item?id=37174698 https://news.ycombinator.com/item?id=37174698
- layer8 3y ago
  I’m not the parent, but exception declarations are IMO necessary for a stable API contract. It’s exactly the same reason why return types are explicit. The actual issue in Java is that you can’t abstract over an arbitrary-length list (sum) of checked-exception types (variadic type parameters) (with the exception of rethrowing from multi-catch clauses).
- brabel 3y ago
  Well, that's kind of true! The fact checked Exceptions are inconvenient doesn't change the fact they are equivalent to returning a Result type (the implementation is obviously different but I think we don't need to mention that). A future version of Java could totally make it more convenient, and perhaps even make the implementation cheaper such that it would not just nearly the same , but literally the same as in Rust or other similar languages.
  - piaste 3y ago
    Does it even need a new language version? If the compiler already spits out the error "hey, your Fart() function should be annotated with 'throws ButtsException'", couldn't an IDE relatively easily be configured to automatically add the " throws " annotations?
    - brabel 3y ago
      Have you ever used Java?? Any half decent IDE has done that since 2000.
      - piaste 3y ago
        Never in anger - I've done some JVM coding, but always in Kotlin (which doesn't have checked exceptions). If Java IDEs have been able to automatically take care of checked exceptions forever, then why do people say that they're inconvenient?
        brabel 3y ago
        Because the people saying that usually do not program in Java.

layer8 3y ago

Checked exceptions are one of the main reasons I’m sticking with Java, even though Java lacks the ability to abstract over sets of checked exceptions, which does cause some inconvenience. It’s unfortunate that no other mainstream languages have been taking that approach.

1-more 3y ago
That sounds awesome! Do you have that flag set on a big codebase? Was it a big hassle to turn it on (like you had to remediate a bunch of code that didn't handle exceptions before you could check it in). Have you seen any big changes since enabling it?
- gbear605 3y ago
  Checked exceptions in Java are the default state and much of the standard library uses them.
wizzwizz4 3y ago
In languages with a Result type (or Either monad), you basically do have checked exceptions, even though the language has no exceptions.
- ivolimmen 3y ago
  Java also has that option. There is an excellent library called vavr. It adds the Try and Either monad to Java.
- layer8 3y ago
  With result types, you typically don’t get automatic exception propagation. I agree that overall it’s a spectrum of syntactic convenience, checked exceptions effectively form a sum type together with the regular return type.

thuridas 3y ago

After working with railway oriented programming with Arrow in Kotlin I had the same feeling of using checked exceptions. And please make the Errors generically wrappable in order to avoid losing the traces.