4 ms·
I don't think checked exceptions have many defenders left... even among their original proponents. And no language (at least no significant one) really copied J
by V-2 8y ago
I don't think checked exceptions have many defenders left... even among their original proponents. And no language (at least no significant one) really copied Java in this regard, as far as I'm aware.
I can't speak for Kotlin users en masse, but personally I don't miss checked exceptions one bit, same as I didn't miss them in C#. And I've never encountered the practice of "dropping back to Java" for checked exceptions of all the reasons.
A compelling way of emulating the presumed benefits - without the bad parts - in Kotlin would be to go sort of functional and use a Try return type from Arrow-Kt: https://arrow-kt.io/docs/arrow/core/try/ https://arrow-kt.io/docs/arrow/core/try/
- iainmerrick 8y agoSo you’re in the “avoid using exceptions” camp? I was trying to figure out if people are happily using unchecked exceptions, or not using them at all.
- V-2 8y agoI'm against using exceptions for flow control (that's nothing else but "goto" in disguise), and against handling exceptions far from where they occur. I would deliberately throw exceptions as a "fail fast" safety switch, when I actually want the thing to burn down in flames. That's typically about violating some sort of a contract which indicates an implementation error - like an illegal argument. In such case to have them unhandled is sort of the point. I found that following these principles by itself leads to a very limited role of exceptions in code.