4 ms·

The main caveat is that oftentimes, checked exception handling doesn't compose well - see what kind of trouble Java gives you, for example. Recent articles I'v

The main caveat is that oftentimes, checked exception handling doesn't compose well - see what kind of trouble Java gives you, for example. Recent articles I've read on effect modeling languages seems to give a more uniform construct for bringing checked exceptions in line with other control constructs.

layer8 5y ago
> see what kind of trouble Java gives you, for example. I program a lot in Java, and the only trouble there is the lack of support for sum types and/or variadic type parameters in generics (i.e. to express functional interfaces that can throw an arbitrary number of checked exceptions, as a type parameter). That’s the only pain point for me and is something that could be fixed. In fact, the interplay with control structures is exactly what I was referring to by syntactic sugar. Indeed it also concerns the type system. But let’s talk about that, not about exceptions good/bad or error values good/bad. That’s too simplisitic.
- deleted 5y ago
  [deleted]
- Fellshard 5y ago
  I mean, syntactic sugar is one thing, but being entirely incapable of creating variadic exceptions really hamstrings you in places where you don't wish to write a great deal of redundant code for each combination of exceptions you may see.
  - layer8 5y ago
    Completely agreed about variadic exceptions, but that's not a drawback of exceptions, it's a limitation of Java's supported syntax for generics. In catch clauses, Java already has exception sum types (`catch (FooException | BarException ex)`), and Java also has variadic method parameters, so why not have variadic type parameters, maybe something like `Foo<V extends Bar, T... extends Throwable>` that can be instantiated as `Foo<SomeBar, BazException | QuxException>`.
    - Fellshard 5y ago
      Yep! I'd love to see something like this in Java, but it's unlikely, probably for the usual runtime type erasure reasons. Exceptions can be implemented in this way, and would strike a nice balance in doing so.

layer8 5y ago

> see what kind of trouble Java gives you, for example. I program a lot in Java, and the only trouble there is the lack of support for sum types and/or variadic type parameters in generics (i.e. to express functional interfaces that can throw an arbitrary number of checked exceptions, as a type parameter). That’s the only pain point for me and is something that could be fixed. In fact, the interplay with control structures is exactly what I was referring to by syntactic sugar. Indeed it also concerns the type system. But let’s talk about that, not about exceptions good/bad or error values good/bad. That’s too simplisitic.

deleted 5y ago
[deleted]
Fellshard 5y ago
I mean, syntactic sugar is one thing, but being entirely incapable of creating variadic exceptions really hamstrings you in places where you don't wish to write a great deal of redundant code for each combination of exceptions you may see.
- layer8 5y ago
  Completely agreed about variadic exceptions, but that's not a drawback of exceptions, it's a limitation of Java's supported syntax for generics. In catch clauses, Java already has exception sum types (`catch (FooException | BarException ex)`), and Java also has variadic method parameters, so why not have variadic type parameters, maybe something like `Foo<V extends Bar, T... extends Throwable>` that can be instantiated as `Foo<SomeBar, BazException | QuxException>`.
  - Fellshard 5y ago
    Yep! I'd love to see something like this in Java, but it's unlikely, probably for the usual runtime type erasure reasons. Exceptions can be implemented in this way, and would strike a nice balance in doing so.