try-catchからrunCatchingに 移行した話 安齋祐紀 (@off2white)

自己紹介 安齋祐紀（あんざいゆうき） Twitter: @off2white 株式会社 ディー・エヌ・エー（DeNA） - 次世代タクシー配車サービス「 MOV」 - Androidアプリ開発担当 - プロジェクト管理とコーディングの割合 = 50:50 (気持ちは) 最近の悩み いまだに運営さんが採択時に 人を間違えていなかったのか心配

No content

背景 個人的エラーハンドリング の変遷

その１
 むやみに例外を使わなくなった

ClassA ClassB ClassC Exception New ClassD 誰が Catch する？ NewException Not For Me Exception ？

ClassA ClassB ClassC sealed class New ClassD I Like sealed class sealed class

ViewModel Repository Api Exception New DB ただし現実的にはこんな感じ sealed class Exception

その２
 Crashlyticsの発達によって 細かくExceptionをCatchする必要が なくなった

蘇る悪夢 try {
 response = apiRequest.execute() 
 dao.save(response.toEntity())
 
 } catch (e: IOException) {
 errorCode += “01”
 throw NetworkException(errorCode) 
 
 } catch (e: SQLException) {
 errorCode += “03”
 throw GeneralException(errorCode) 
 
 } catch (e: Throwable) {
 errorCode += “04”
 throw SystemException(errorCode) 
 
 }


その３
 Rx -> Coroutineへの移行

Rx では success と error 時の処理を 分けて記載できた repository.fetchData()
 
 .subscribeBy (
 onNext = { livedata.postValue(it)},
 
 onError = { Timber.e(it) }
 )
 実 行 系 正 常 系 異 常 系

もっと良いエラーハンドリングの書き方はないのか


runCatching (Kotlin 1.3)


runCatching {
 apiRequest.execute()
 } 
 
 or 
 
 apiRequest.execute()
 .runCatching {
 dao.save(it.toEntity())
 } 
 こんな感じで書く


 runCatchingは Resultクラスを返却する

成功結果と例外を カプセル化してくれる

val result = runCatching {
 apiRequest.execute()
 }
 
 if (result.isFailure) {
 Timber.e(
 result.exceptionOrNull()
 )
 return
 }
 処理結果を受け取って 返却してくれる

runCatching {
 apiRequest.execute()
 }.onSuccess {
 dao.save(it.toEntity())
 }.onFailure {
 Timber.e(it)
 }
 成功処理と失敗処理を 分けて記載できる 実 行 系 正 常 系 異 常 系

runCatching {
 apiRequest.execute()
 }.mapCatching {
 dao.save(it.toEntity())
 }.onSucess {
 …
 }.onFailure {
 ...
 }
 map 時も Catch できる

runCatching {
 apiRequest.execute()
 }.recoverCatching {
 Response.default()
 }
 例外処理のリカバリ処 理も綺麗にかける


 これは是非使うべき！！！

結論
 案外不評


try {
 res = apiClient.execute()
 dao.save(res.toEntity())
 }
 catch (e: Exception) {
 Timber.e(e)
 } 
 正常パスと 例外処理で 別れている方が 好みの人もいる 正 常 パ ス 例 外 処 理 理由その１


val a: Int? = 
 try { parseInt(input) } catch (e: Exception) 
 { null }
 Kotlin の try-catch は式 として書けるので それで十分説 理由その２


val a: Int? = 
 try { parseInt(input) } catch (e: Exception) 
 { null }
 finally { ... }
 try-catch なら finally で 明示的に書ける (runCatching ではできない ) 理由その３


return runCatching {
 …
 }
 Result 型は return できない 理由その４


fun function() : Int {
 runCatching {
 "5".toInt()
 }.onSuccess {
 return@function it
 }.onFailure {
 return@function 0
 }
 // ここにreturnが必要
 }
 a ‘return’ expression required in a function with a block body 理由その５


(;Ծ﹏Ծ)ぐぬぬ


runCatching {
 runFunction()
 }.onSuccess {
 dispatch(Action.Success)
 }.onFailure {
 dispatch(Action.Failure)
 }
 現状は return しない ところで そっと使っている ActionCreator の dispatch とか ViewModel の LiveData.postValue とか

Resultクラスの
 KEEPでの議論が面白いので
 ぜひ読んでね！