4 ms·
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
by _flux 5y ago
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.
- masklinn 5y agoIn 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, …
- jpgvm 5y agoCorrect. There is probably a model for checked exceptions that is good but it's current state in Java isn't it. Kotlin did the right thing by not implementing checked exceptions for now.
- masklinn 5y ago> 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.