3 ms·

Here’s a random question on Kotlin, hopefully not too controversial... I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in

Here’s a random question on Kotlin, hopefully not too controversial... I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in every way. The one big difference is checked exceptions -- Kotlin doesn’t have them. My question is, do Kotlin users prefer unchecked exceptions, or do you find yourself avoiding exceptions entirely now? Or even dropping back to Java when you need exceptions and you want compile-time checks? I find myself mostly trying to avoid exceptions entirely in Kotlin -- maybe not such a bad thing!

aembleton 8y ago
If I want an exception, then I don't want it checked otherwise I have to handle it at every layer in which case I may as return a nullable object and handle that. I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.
guiye 8y ago
Use some lib like vavr (ex javaslang) for catching exceptions into a Try object, a simple functional solution
- iainmerrick 8y ago
  Sure, but without checked exceptions, the compiler won’t tell you whether you’re catching/wrapping the right exceptions in the right places.
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 ago
  So 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 ago
    I'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.

aembleton 8y ago

If I want an exception, then I don't want it checked otherwise I have to handle it at every layer in which case I may as return a nullable object and handle that. I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.

guiye 8y ago

Use some lib like vavr (ex javaslang) for catching exceptions into a Try object, a simple functional solution

iainmerrick 8y ago
Sure, but without checked exceptions, the compiler won’t tell you whether you’re catching/wrapping the right exceptions in the right places.

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 ago
So 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 ago
  I'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.