-2

The following method will warn about IOException if called in Java code but will simply ignore any warning in Kotlin because IOException is a checked exception.

ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_WRITE)

Java forces developers to take safe action in case it throws an exception but in Kotlin it just overlooks the exception creating a potential bug source. I'm quite sure there are lots of similar cases where checked exception is simply ignored.

The question is how to handle such cases?

Farid
  • 2,317
  • 1
  • 20
  • 34
  • I am not sure I understand your question. Are you asking about how to handle exceptions in Kotlin? Or why Kotlin doesn't have checked exceptions in the first place? – Henry Twist Apr 02 '21 at 14:28
  • Kotlin's sealed classes are a means to solve the same issues as checked exceptions, while avoiding the major criticisms of checked exceptions. The primary problem is when working with Java libraries. – Tenfour04 Apr 02 '21 at 15:28

2 Answers2

0

Java will not warn you if method is throwing unchecked exception, how are you handling this case? The best you can do here is to check java doc or the source of the calling method to see if it throws any exceptions. Or just to catch any exception somewhere in your code which calls this method.

If you are asking why Kotlin doesn't have checked exceptions unlike java, the official Kotlin docs about exceptions provides an explanation why they decided to move away from checked exceptions. Quote:

Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result – decreased productivity and little or no increase in code quality.

UPD: Article by kotlin lang architect about this matter: https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07

Flame239
  • 1,274
  • 1
  • 8
  • 20
0

Kotlin doesn't prevent you from catching any or all exceptions; it just doesn't force you to do so, like Java does.

So you can still do e.g.:

try {
    ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_WRITE)
} catch (x: IOException) {
    // …
}

As for how you know that the method could throw an IOException… that's tricky.  If it's a Java method, then of course its JavaDoc will specify it (and you can see that from your IDE).  But if it's Kotlin, well, the documentation might say; or if you have the source code, you could check that.  But I'm afraid there's no real way to know!  All you can do is guess — and ensure that you catch all exceptions at critical points.

Treating all exceptions as unchecked is not without controversy; see this long-running discussion.

There are clearly a few situations where Java-style checked exceptions would be impractical: for example, when calling lambdas or function references.  (Java itself forces you to handle or wrap checked exceptions in such cases, which can be unwieldy.)  For big programs which cover multiple layers of abstraction, there's the problem of exceptions bubbling up to a point where they make little sense; the usual solution there is exception translation: catching them and rethrowing more appropriate ones.  And there's also the problem that too many bad developers simply catch all exceptions and ignore them (or, at best, log them) without considering how or where they should be handled.

But you might well think that dropping all exception checking is throwing the baby out with the bathwater…

(I've suggested that Kotlin should do exception inference — working out which uncaught exceptions a method could throw, and assuming a @Throws declaration for them — which would solve most of the problems around knowing which exceptions could be thrown at any point, without requiring them to be caught or invalidating any existing code.  But I'm probably failing to see some problems around that, because while it seems an obviously good idea to me, it hasn't been well received…)

gidds
  • 16,558
  • 2
  • 19
  • 26