Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Don’t use runCatching

Don’t use runCatching

LY Corporation
OISHI Masakuni

※この資料は以下イベントで発表した内容です。
https://shibuya-apk.connpass.com/event/299317/

LY Corporation Tech

November 10, 2023
Tweet

More Decks by LY Corporation Tech

Other Decks in Technology

Transcript

  1. 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.
  2. DO NOT catch all Throwables • Of cause, the code

    “try { … } catch (e: Throwable) { … }” catches all Throwables, including Errors. Thus, you must not do so.
  3. 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.
  4. DO NOT catch CancellationException! • In Kotlin Coroutines, cancellation is

    performed by throwing a CancellationException. • Catching a CancellationException breaks the cancellation mechanism of coroutines.
  5. 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.
  6. 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.
  7. 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)
  8. 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
  9. Not the best code, but not too bad • Catch

    all Exceptions except CancellationException. • But note that this makes it harder to fi nd bugs.
  10. 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!