try-catchからrunCatchingに_移行した話.pdf

Transcript

1. try-catchからrunCatchingに 移行した話 安齋祐紀 (@off2white)
2. 自己紹介 安齋祐紀（あんざいゆうき） Twitter: @off2white 株式会社 ディー・エヌ・エー（DeNA） - 次世代タクシー配車サービス「 MOV」 - Androidアプリ開発担当 - プロジェクト管理とコーディングの割合 = 50:50 (気持ちは) 最近の悩み いまだに運営さんが採択時に 人を間違えていなかったのか心配
4. 背景 個人的エラーハンドリング の変遷
5. その１
 むやみに例外を使わなくなった
6. ClassA ClassB ClassC Exception New ClassD 誰が Catch する？ NewException Not For Me Exception ？
7. ClassA ClassB ClassC sealed class New ClassD I Like sealed class sealed class
8. ViewModel Repository Api Exception New DB ただし現実的にはこんな感じ sealed class Exception
9. その２
 Crashlyticsの発達によって 細かくExceptionをCatchする必要が なくなった
10. 蘇る悪夢 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) 
 
 }

11. その３
 Rx -> Coroutineへの移行
12. Rx では success と error 時の処理を 分けて記載できた repository.fetchData()
 
 .subscribeBy (
 onNext = { livedata.postValue(it)},
 
 onError = { Timber.e(it) }
 )
 実 行 系 正 常 系 異 常 系
13. もっと良いエラーハンドリングの書き方はないのか

14. runCatching (Kotlin 1.3)

15. runCatching {
 apiRequest.execute()
 } 
 
 or 
 
 apiRequest.execute()
 .runCatching {
 dao.save(it.toEntity())
 } 
 こんな感じで書く
16. 
 runCatchingは Resultクラスを返却する
17. 成功結果と例外を カプセル化してくれる
18. val result = runCatching {
 apiRequest.execute()
 }
 
 if (result.isFailure) {
 Timber.e(
 result.exceptionOrNull()
 )
 return
 }
 処理結果を受け取って 返却してくれる
19. runCatching {
 apiRequest.execute()
 }.onSuccess {
 dao.save(it.toEntity())
 }.onFailure {
 Timber.e(it)
 }
 成功処理と失敗処理を 分けて記載できる 実 行 系 正 常 系 異 常 系
20. runCatching {
 apiRequest.execute()
 }.mapCatching {
 dao.save(it.toEntity())
 }.onSucess {
 …
 }.onFailure {
 ...
 }
 map 時も Catch できる
21. runCatching {
 apiRequest.execute()
 }.recoverCatching {
 Response.default()
 }
 例外処理のリカバリ処 理も綺麗にかける
22. 
 これは是非使うべき！！！
23. 結論
 案外不評

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

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

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

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

28. 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 理由その５

29. (;Ծ﹏Ծ)ぐぬぬ

30. runCatching {
 runFunction()
 }.onSuccess {
 dispatch(Action.Success)
 }.onFailure {
 dispatch(Action.Failure)
 }
 現状は return しない ところで そっと使っている ActionCreator の dispatch とか ViewModel の LiveData.postValue とか
31. Resultクラスの
 KEEPでの議論が面白いので
 ぜひ読んでね！