3 ms·

You could solve that with sum types (for 2+ exceptions) and never types (for 0),

lmm 7y ago
It's not actually a sum, it's an inclusive union which are much harder to reason about and compromise your type system more (IMO). In any case, Java does not have any of those, and this is what makes checked exceptions impractical to work with; Rust has sum types but I don't think it has either inclusive unions or never types.
- Nullabillity 7y ago
  > 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.

lmm 7y ago

It's not actually a sum, it's an inclusive union which are much harder to reason about and compromise your type system more (IMO). In any case, Java does not have any of those, and this is what makes checked exceptions impractical to work with; Rust has sum types but I don't think it has either inclusive unions or never types.

Nullabillity 7y ago
> 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.