>This irks me too. It's been a while but I believe the workaround is just to define your own (checked) FunctionE, SupplierE, ConsumerE functional interfaces. But maybe that causes other problems I've forgotten.
You can do that, but you need to do it for every exception type ): I'd love it if Java had templated exceptions.
>> the stupid distinction between primitive types and Objects
One of the slowest things I found out about C# was floats being objects and `a < b` (or something similar) being a stack about 7 levels deep.
You can do this, but it's not ideal. A function can list multiple exceptions in its throws clause, which share no common type except Throwable, but this combination of exception types can't be represented by a single type parameter (except for the common base type). So in a lot of cases, you lose information about the specific exceptions your function can throw, which limits the value of using checked exceptions.
That's right, I would run into even bigger performance issues if I used Integer/Long/Double/etc everywhere instead of the primitive types. The problem is not that primitive types are not object, but rather, that generic code will only accept objects and not primitive types.
The other alternative is to use the error monad in combination with railroad style programming. Of course you also want infix operators like (>>), (>>?) aso.
You can do that, but you need to do it for every exception type ): I'd love it if Java had templated exceptions.
>> the stupid distinction between primitive types and Objects
One of the slowest things I found out about C# was floats being objects and `a < b` (or something similar) being a stack about 7 levels deep.