Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
try-catchからrunCatchingに_移行した話.pdf
Search
yuki anzai
August 24, 2019
Programming
6
3.1k
try-catchからrunCatchingに_移行した話.pdf
yuki anzai
August 24, 2019
Tweet
Share
More Decks by yuki anzai
See All by yuki anzai
5分でざっくり理解する Jetpack Compose
kuromame
0
200
Flux + Repositoryへリアーキテクチャ後にテストを書き始めて1ヶ月経った話
kuromame
4
340
Other Decks in Programming
See All in Programming
Sidekiqで実現する 長時間非同期処理の中断と再開 / Pausing and Resuming Long-Running Asynchronous Jobs with Sidekiq
hypermkt
6
2.7k
Tuning GraphQL on Rails
pyama86
2
1k
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
d_endo
1
1k
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.5k
Googleのテストサイズを活用したテスト環境の構築
toms74209200
0
270
macOS でできる リアルタイム動画像処理
biacco42
6
1.7k
Amazon Neptuneで始めてみるグラフDB-OpenSearchによるグラフの全文検索-
satoshi256kbyte
4
320
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
1.6k
Vaporモードを大規模サービスに最速導入して学びを共有する
kazukishimamoto
4
4.3k
僕がつくった48個のWebサービス達
yusukebe
18
17k
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
9
990
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
Designing for humans not robots
tammielis
249
25k
Raft: Consensus for Rubyists
vanstee
136
6.6k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
Into the Great Unknown - MozCon
thekraken
31
1.5k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
RailsConf 2023
tenderlove
29
880
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
290
Six Lessons from altMBA
skipperchong
26
3.5k
Transcript
try-catchからrunCatchingに 移行した話 安齋祐紀 (@off2white)
自己紹介 安齋祐紀(あんざいゆうき) Twitter: @off2white 株式会社 ディー・エヌ・エー(DeNA) - 次世代タクシー配車サービス「 MOV」 -
Androidアプリ開発担当 - プロジェクト管理とコーディングの割合 = 50:50 (気持ちは) 最近の悩み いまだに運営さんが採択時に 人を間違えていなかったのか心配
None
背景 個人的エラーハンドリング の変遷
その1 むやみに例外を使わなくなった
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
その2 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) }
その3 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) } 正常パスと 例外処理で 別れている方が 好みの人もいる 正 常 パ ス 例 外 処 理 理由その1
val a: Int? = try { parseInt(input) } catch
(e: Exception) { null } Kotlin の try-catch は式 として書けるので それで十分説 理由その2
val a: Int? = try { parseInt(input) } catch
(e: Exception) { null } finally { ... } try-catch なら finally で 明示的に書ける (runCatching ではできない ) 理由その3
return runCatching { … } Result 型は return できない 理由その4
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 理由その5
(;Ծ﹏Ծ)ぐぬぬ
runCatching { runFunction() }.onSuccess { dispatch(Action.Success) }.onFailure { dispatch(Action.Failure) }
現状は return しない ところで そっと使っている ActionCreator の dispatch とか ViewModel の LiveData.postValue とか
Resultクラスの KEEPでの議論が面白いので ぜひ読んでね!