5 ms·

I think the transformative potential for error handling in Java cannot be overstated. Effectively, this means exceptions can be handled as errors without pollut

I think the transformative potential for error handling in Java cannot be overstated. Effectively, this means exceptions can be handled as errors without polluting the return type with an ever-growing list of error-monads. The following example shows this nicely: > Future<String> f = ... > switch (f.get()) { > case String s -> process(s); > case throws ExecutionException(var underlying) -> throw underlying; > case throws TimeoutException e -> cancel(); > } Note that I don't get the hate for exceptions. Sometimes, handeling the error somewhere up the callstack is exactly the right solution. The problem was that Java did not have convenient syntax for handeling exceptions at call-site. FYI: There was also an interesting discussion in the Java mailing lists also going into some implementation details regarding the representing bytecode: https://mail.openjdk.org/pipermail/amber-spec-experts/2023-December/003959.html https://mail.openjdk.org/pipermail/amber-spec-experts/2023-D...

lichtenberger 3y ago
I think it depends, but I wonder if anything can be done about the problem with checked exceptions in lambdas / for instance the streams. I think the enhanced switch with handling failure is only part of the solution, but I'm also a proponent of having only unchecked exceptions.
- DarkNova6 3y ago
  I think the Java team is getting there. Everything in the sytanx-space they have worked on moved towards a functional representation of data. Once you have a uniform way to describe non-uniform types (sum types, rust enums etc.), adding exception support to the JDK seems trivial. I've actually made small streaming libraries which also support exceptions, but the problem is that it only works well if you need to support a single exception type. As far as I'm concerned, I like checked exceptions because it improves discoverability, documentation and makes exceptional control flow more visible when reading code (including code reviews).

lichtenberger 3y ago

I think it depends, but I wonder if anything can be done about the problem with checked exceptions in lambdas / for instance the streams. I think the enhanced switch with handling failure is only part of the solution, but I'm also a proponent of having only unchecked exceptions.

DarkNova6 3y ago
I think the Java team is getting there. Everything in the sytanx-space they have worked on moved towards a functional representation of data. Once you have a uniform way to describe non-uniform types (sum types, rust enums etc.), adding exception support to the JDK seems trivial. I've actually made small streaming libraries which also support exceptions, but the problem is that it only works well if you need to support a single exception type. As far as I'm concerned, I like checked exceptions because it improves discoverability, documentation and makes exceptional control flow more visible when reading code (including code reviews).