5 ms·
The biggest issue with checked exceptions in modern Java is that even the Java makers themselves have abandoned them. They don't work well with any of the fancy
by LinXitoW 2y ago
The biggest issue with checked exceptions in modern Java is that even the Java makers themselves have abandoned them. They don't work well with any of the fancy features, like Streams.
Checked Exceptions are nothing but errors as return values plus some syntactic sugar to support the most common response to errors, bubbling.
- gf000 2y ago> They don't work well with any of the fancy features, like Streams. Because that would require effect types, which is quite advanced/at a research level currently.
- layer8 2y agoAll it would require is more support for sum types and variadic type parameters, and maybe fix some hiccups in the existing type inference. You can already write a Stream-like API that supports up to a fixed number of exception types (it’s just a bit annoying to write). The main issue at present is that you can’t do it for an open-ended number of exception types and abstract over the concrete set of types.
- gf000 2y agoThe throws clause would require union types, not sum types though (you can observe it in the catch part of a try catch, e.g. `catch ExceptionA | ExceptionB`. But java can't support unions elsewhere, it will have to be replaced by the two exceptions' common supertype.
- layer8 2y agoI was subsuming union types under sum types here, maybe a bit imprecisely. The following already works in Java (and has for a long time): interface F<X extends Exception, Y extends Exception> { void f(int n) throws X, Y; } void g() throws IOException, SQLException { F<IOException, SQLException> f = n -> { if (n > 0) throw new IOException(); else throw new SQLException(); }; h(f, 0); } <X extends Exception, Y extends Exception> void h(F<X, Y> f, int n) throws X, Y { f.f(n); } We merely want for F and h to be able to work for any number of exception types. We don't need the ability to declare variables of type X | Y for that. Of course, it would be nice not having to write IOException, SQLException multiple times in g, and instead have some shortcut for it, but that's not strictly necessary. The main problem currently is that you have to define F1, F2, F3,... as well as h1, h2, h3,... to cover different numbers of exception types, instead of having just a single definition that would abstract over the number of exception types.
- ndriscoll 2y agoScala's zio library basically gives you checked exceptions that work with things like type inference, streams, async operations, and everything else.