Checked exceptions failed in Java because they don't play well with parametric polymorphism. Union types might help (exception list declaration is actually a union type) but I don't think it would succeed anyway as it is not general enough.
Handling effects and effect polymorphism in programming languages is an active area of research and there are some new languages that try to approach the problem (ie. Koka).
Haskell has several effect libraries (effectful, cleff, eff, polysemy) that look quite nice.
Idris with its dependent types allows precise definition of effects in function signatures.
No, that's not it. The same problem is true for other error-handling types, such as the "either" or "result" types. Languages without union types or a similar mechanism are unable to define the error types adhoc and force the developer to define them in advance, which is very unergonomic.
But that is true in both cases. The problems with checked exceptions come on top, namely that you cannot use all the regular value-machinery to transform and manipulate the result of a function-call.
> No, that's not it. The same problem is true for other error-handling types, such as the "either" or "result" types. Languages without union types or a similar mechanism are unable to define the error types adhoc and force the developer to define them in advance, which is very unergonomic
We are saying the same thing, aren't we?
But it is not only about exceptions. Other effects have the same problem and you need a mechanism to define effect polymorphic functions.
Handling effects and effect polymorphism in programming languages is an active area of research and there are some new languages that try to approach the problem (ie. Koka).
Haskell has several effect libraries (effectful, cleff, eff, polysemy) that look quite nice.
Idris with its dependent types allows precise definition of effects in function signatures.