Not saying this is a good idea or a bad idea - but I could see the use in a function that could both error from a bad file or a dropped network function. You don't really want to combine those two into one enum or error class, but maybe your programming language has support for marking the types of errors a function can return and ensuring coverage.
I think one big reason why checked exceptions failed was due to the other big lacking thing: generics. Of course, nowadays Java does have generics but I haven't used Java since then.
But in principle with generics and possibly some other additions you could provide much more useful checked exception types: ones that are applicable to your situation and would allow you to bubble up more precise checked exceptions.
In reality generics made checked exceptions a lot worse because while you can be generic over checked exceptions you can’t be generic over their combinations, do you can not have a wrapper which is “transparent” to exceptions (e.g. swift’s “rethrows”).
You need a wrapper for 0 exceptions, a wrapper for 1, a wrapper for 2, …
> There is probably a model for checked exceptions that is good but it's current state in Java isn't it.
Yeah and Java has pretty thoroughly poisoned that well so in every discussion of the concept what comes up is mostly Java’s implementation and then it’s dead on arrival.
And then you’ve got Swift which uses an exception-ish syntax for results, but they’re not even remotely exceptions, and functions must say that they are faillible (or failure-transparent) but then can’t say what their failures are, so it always feels like the worst of both worlds.
Though it makes more sense when you understand that it’s dual to the old `NSError*` out-parameter system.
Can you explain to me why it was bad? I've not used Java (professionally at least) - from what I can tell, the main issue is that it's just much more verbose than returning something like Result<T>.
