Thanks for the reply. I know my comment was very blunt, and didn't mean to cause offence - hope you didn't take any.
The reason I responded like that was that I really disagree with many Rust users who keep saying Rust error handling is so much better in every way and that Exceptions are stupid and stuff like that... and I was responding to those kind of people, not really you as your post was well balanced.
> In the end, this is a subjective judgement call that everyone makes based on their own experience. My experience doesn't match yours here.
Absolutely. Subjective topics can still be discussed, but yeah we're very unlikely to all agree, ever.
> I don't know an equivalent in Java that simultaneously...
Well, the way you do it in Java is using OOP: basically, have a single Exception type at the root of the Exception type hierarchy and make your library only throw sub-types of that. Then you may handle specializations of that, but you need to also handle the root type in case an unknown variant comes along. That leaves your last point unaddressed, but you can either make the root type a sealed interface, or have an enum describing all cases, so that the caller can opt-in to have their code break if they fail to handle one of the cases in the future.
> have a single Exception type at the root of the Exception type hierarchy and make your library only throw sub-types of that. Then you may handle specializations of that, but you need to also handle the root type in case an unknown variant comes along.
Hm, I haven't considered this solution. It works exactly like a #[non-exhaustive] enum. It's a wrapper type that provides type info about specific known variants (subclasses) but also still forces the caller to `catch MyBaseException` (match `_ => {..}`). I may need to update the post. Now it seems that #[non-exhaustive] error handling is equivalent in both cases and the main issue with Java lies in generic code [1]
> In the end, this is a subjective judgement call that everyone makes based on their own experience. My experience doesn't match yours here.
Absolutely. Subjective topics can still be discussed, but yeah we're very unlikely to all agree, ever.
> I don't know an equivalent in Java that simultaneously...
Well, the way you do it in Java is using OOP: basically, have a single Exception type at the root of the Exception type hierarchy and make your library only throw sub-types of that. Then you may handle specializations of that, but you need to also handle the root type in case an unknown variant comes along. That leaves your last point unaddressed, but you can either make the root type a sealed interface, or have an enum describing all cases, so that the caller can opt-in to have their code break if they fail to handle one of the cases in the future.