OISHI Masakuni Don’t use runCatching LY Corporation

What is the problem with this code?

runCatching catches ALL Throwables =

Exceptions Hierarchy in Kotlin Throwable Exception Error RuntimeException IOException NullPointerException CancellationException

Throwable Exception Error RuntimeException IOException NullPointerException CancellationException This is System Error. Don’t catch!

DO NOT catch Errors! • Error is considered an unrecoverable exception, and when it is thrown, apps should be terminated immediately. • Errors may be thrown from almost anywhere. (e.g. OutOfMemoryError) • If the app catches an Error and continues processing, the behavior of the app becomes unpredictable and can cause more serious problems.

DO NOT catch all Throwables • Of cause, the code “try { … } catch (e: Throwable) { … }” catches all Throwables, including Errors. Thus, you must not do so.

Do not implement own logging code for Throwable • Do not implement your own logging code when the app crashes. • Leave the crash logging to an application-wide framework such as Firebase Crashlytics.

Throwable Exception Error RuntimeException IOException NullPointerException CancellationException This is used for coroutine cancellation. Don’t catch! Don’t catch!

DO NOT catch CancellationException! • In Kotlin Coroutines, cancellation is performed by throwing a CancellationException. • Catching a CancellationException breaks the cancellation mechanism of coroutines.

Throwable Exception Error RuntimeException IOException NullPointerException CancellationException Usually, this is caused by bugs. Don’t catch! Don’t catch! Don’t catch!

Refrain from catching RuntimeException • RuntimeException is often thrown due to bugs. (e.g. NullPointerException) • It is a bad practice to ignore exceptions caused by bugs and continue processing. • When an exception is thrown due to a bug, the app should crash without catching it. This will make it easier to fi nd the bug in tests. • Ignoring exceptions caused by bugs may cause more serious problems.

A real problem we had in our app • There was a bug in a task that sends data to the server, throwing a NullPointerException. • The task was implemented to catch all exceptions and simply retry. • This bug resulted in in fi nite repetition of data transmission and a huge increase in the app's traf fi c. • We were not aware of this bug until the user complained.

Throwable Exception Error RuntimeException IOException NullPointerException CancellationException You should catch this! Don’t catch! Don’t catch! Don’t catch!

Catch specific types of exceptions • In general, failures related to interactions with outside of the app process are the exceptions that should be caught. For example, • IOException • Parsing error in API payload (e.g. JSONException) • Catch these exceptions in as speci fi c types as possible. • Note that in some libraries, even exceptions related to I/O operations extend RuntimeException. (e.g. retro fi t2.HttpException)

Summary • Do not catch Error • Of cause, do not catch ALL Throwables • Do not catch CancellationException • Refrain from catching RuntimeException • But some RuntimeException should be caught (e.g. retro fi t2.HttpException) • Catch speci fi c types of Exceptions

Best Practice • Catch expected exceptions with their speci fi c types.

Not the best code, but not too bad • Catch all Exceptions except CancellationException. • But note that this makes it harder to fi nd bugs.

Catch specific types of exceptions Throwable Exception Error RuntimeException IOException NullPointerException CancellationException You should catch this! Don’t catch! Don’t catch! Don’t catch!

Do not use runCatching!