[kaba0]

Which is the imo correct approach. Instead of unwrapping and rewrapping the exception at the closest level, I want to handle most exceptions in a common place. Eg, in case of a web server that place would give a proper error page to the user whenever an unhandled exception happened in his/her request.

Also, Java’s exceptions are pretty much the exact same sum type as in Rust, just with added syntactic sugar. A method with a throws SomeException signature will have a type of Result<Something> | Error<SomeException>, that gets autounwrapped for you, with the added benefit of giving you a stacktrace by default.

[pharmakom]

> Java’s exceptions are pretty much the exact same sum type as in Rust, just with added syntactic sugar.

Except Java doesn’t actually return a result object that can be assigned to a variable by default.

[kaba0]

And in case of exceptions, why would that be useful?

(For other things, I agree that sum types are cool, and fortunately are supported in Java through sealed classes)

[pharmakom]

I don’t think sealed classes offer exhaustive pattern matching. Instead you have an if-else ladder of instanceof checks. This is not the same as most union type implementations.

[kaba0]

They do with switch expressions. It is only type based for now, but deconstructs are coming with full blown pattern matching a la Haskell.