3 ms·

> It's not actually a sum, it's an inclusive union Right, whoops. My bad! > In any case, Java does not have any of those, and this is what makes checked excep

> It's not actually a sum, it's an inclusive union Right, whoops. My bad! > In any case, Java does not have any of those, and this is what makes checked exceptions impractical to work with Absolutely. I was approaching it from the standpoint of "what would I change about Java's type system to make checked exceptions usable?". > Rust has sum types but I don't think it has either inclusive unions or never types. Rust is working on stabilizing a true never type[0], and until then you can emulate it with an empty enum.[1] There is also a RFC for unions, but that doesn't seem to have gone anywere.[2] [0]: https://github.com/rust-lang/rust/issues/57012 https://github.com/rust-lang/rust/issues/57012 [1]: Such as https://crates.io/crates/void https://crates.io/crates/void which also provides helpers for safely coercing `Void` `Result`s [2]: https://github.com/rust-lang/rfcs/pull/1154 https://github.com/rust-lang/rfcs/pull/1154

Quekid5 7y ago
My comment was actually made with many of these issues in mind -- I was trying to avoid needless nitpicking by being a bit vague. Perhaps that was a mistake. The point wasn't that these things couldn't be solved -- they could, at least in theory[0] -- but that the current practical limitations of Java[1] are such that the interaction of higher-order functions and checked exceptions make checked exceptions a really bad idea. [0] At least I think so... given anonymous or adhoc sum types, etc. [1] Interestingly, this is not a JVM-wide issue. It's just the Java compiler that imposes these restrictions, for example: You cannot "catch" a checked exception which hasn't been declared at least one method in the "try" scope. This makes sense at first glance ("cannot happen"), but means that re-wrapping by higher-order functions must entail extremely error-prone inspection of any exception by calling code, etc. etc. It's a huge mess.

Quekid5 7y ago

My comment was actually made with many of these issues in mind -- I was trying to avoid needless nitpicking by being a bit vague. Perhaps that was a mistake. The point wasn't that these things couldn't be solved -- they could, at least in theory[0] -- but that the current practical limitations of Java[1] are such that the interaction of higher-order functions and checked exceptions make checked exceptions a really bad idea. [0] At least I think so... given anonymous or adhoc sum types, etc. [1] Interestingly, this is not a JVM-wide issue. It's just the Java compiler that imposes these restrictions, for example: You cannot "catch" a checked exception which hasn't been declared at least one method in the "try" scope. This makes sense at first glance ("cannot happen"), but means that re-wrapping by higher-order functions must entail extremely error-prone inspection of any exception by calling code, etc. etc. It's a huge mess.