Comment by kbolino

3 months ago

Yeah, the problems seem to largely be ergonomic.

As another example, the exception type hierarchy doesn't pull enough weight. Exception is the base class of all checked exceptions and RuntimeException is the base class of all "ordinary" unchecked exceptions, but it confusingly subclasses Exception. So there's no way to catch only "all checked exceptions". Then, Error is distinct from that hierarchy, but some things that smell like errors were made into exceptions instead (e.g. NullPointerException).

This was compounded by the fact that, in the original design, you could only call out one exception type in a catch statement. So if you had 3 different disjoint exception types that you simply wanted to wrap and rethrow, you had to write 3 different catch blocks for them. Java 7 added the ability to catch multiple exceptions in the same block, but it was too little, too late (as far as redeeming checked exceptions goes).

1 comment

kbolino

vips7L 3 months ago

> So if you had 3 different disjoint exception types that you simply wanted to wrap and rethrow, you had to write 3 different catch blocks for them.

Agreed. There's a proposal for exception catching in switch [0] which I'm hopeful will alleviate a lot of this. I think that jep plus combining exceptions with sealed types the error handling will be convenient and easy.

    sealed abstract class SomeException extends Exception permits AException, BException {};
    
    void someFn() throws SomeException;
   
    // hypothetically handling in switch would let you enumerate the subtypes of the exception
    var a = switch (someFn()) {
        case A a -> a;
        case throws AException aex -> new A();
        case throws BException bex -> throw new RuntimeException(bex);
    };

> As another example, the exception type hierarchy doesn't pull enough weight.

Kotlin has an interesting proposal for their language that creates their own "error" type that will allow type unions [1]. The only thing I worry about is that it further puts Kotlin away from Java making interop a lot harder.

[0] https://openjdk.org/jeps/8323658

[1] https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441...