Koltin Coroutines withContextを使っているとStackTraceを用いた不具合調査が辛いのをどうにかしたい【株式会社ライトコード】

はじめに

Androidの非同期処理でKoltin Coroutinesを用いた実装を数年続けてきたことで
非同期処理を最適化するために
withContextを積極的に使うことを意識して実装するようになりました。
withContextによるスレッドの切り替えは
オーバーヘッドも少なく、気軽に使うことができるのが魅力の一つです。

しかし、withContextを積極的に使った実装をするようになったことで
StackTraceを用いた不具合調査がしづらくなってしまいました。

「不具合調査が辛い」とはどういうことか

端的に言うと。
withContextを使うと「StackTraceが破壊され処理の呼び出し元がわからなくなる」
という問題が辛いです。

例を挙げましょう。

 // 適当なRpository

class HogeRepository(

    private val dispatcherIO: CoroutineDispatcher = Dispatchers.IO

) {

    suspend fun getHoge(): String = withContext(dispatcherIO) {

        throw RuntimeException("適当な例外")

    }

}

これをViewModelで利用したとしましょう。

 // 適当なViewModelから呼び出す

class MainViewModel(

    private val repository: HogeRepository = HogeRepository()

) : ViewModel() {



    fun onClickButton() {

        viewModelScope.launch {

            // 先のRepositoryのメソッド呼び出す

            repository.getHoge()

        }

    }

}

この状態でMainViewModel.onClickButton()を実行して、アプリをクラッシュさせます。

出力されたスタックトレースを見てみましょう。

はい。（行数は例とズレているので気にしないでください）
「HogeRepository.getHoge()内部（性格にはwithContext内部）で例外が発生した」
という情報しかわかりません。

「MainViewModel.onClickButton()から呼ばれた」
という情報が読み取れません。

これでは、不具合調査が難しくなってしまう可能性があります。

困ること

まあ、当たり前といえば当たり前の話ですね。
suspend関数のJVMレベルでの挙動では
「一時的に抜けてあとから再開する」という挙動をしており
物理的なコールスタックが分断されているので、
スタックトレースがこうなってしまうのは仕方ないことです。

いやー
呼び出し箇所が1箇所なら、これでもあまり困りませんが。
以下のように、同じ処理を複数箇所から呼び出されている場合は致命的です。

 // 複数箇所から呼び出すケース

class MainViewModel(

    private val repository: HogeRepository = HogeRepository()

) : ViewModel() {



    fun onClickButton1() {

        viewModelScope.launch { 

            repository.getHoge() // ここでクラッシュ？

        }

    }

    

    fun onClickButton2() {

        viewModelScope.launch { 

            repository.getHoge() // それとも、こっちでクラッシュ？

        }

    }

}