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
2.9k
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
180
Flux + Repositoryへリアーキテクチャ後にテストを書き始めて1ヶ月経った話
kuromame
4
330
Other Decks in Programming
See All in Programming
Scalable Customer Journey Orchestration (CJO)
lewuathe
0
410
Next.js App Router
quramy
11
1.6k
Elm 0.19.0 Changes
bkuhlmann
0
500
try! Swift Tokyo 2024 参加報告 / try! Swift Tokyo 2024 Report
hironytic
0
220
スキーマ駆動開発による品質とスピードの両立 - 私達は何故、スキーマを書くのか
kentaroutakeda
0
180
OpenAPIを中心に考えるAPI開発入門 / Introduction to API Development with a Focus on OpenAPI
seike460
PRO
2
170
R言語の環境構築と基礎 Tokyo.R 112
bob3bob3
0
280
CREってこういうこと? 体験入社 - 提案資料 - / what-is-cre-trial-employment
shinden
1
500
ServerAction で Progressive Enhancement はどこまで頑張れるか? / progressive-enhancement-with-server-action
takefumiyoshii
6
400
障害対応を起点としたもっといい開発と運用のサイクル作りのためにできること / Hatena Enginner Seminar #29
polamjag
0
350
if constexpr文はテンプレート世界のラムダ式である
faithandbrave
3
670
StoreKit2によるiOSのアプリ内課金のリニューアル
kangnux
0
120
Featured
See All Featured
Done Done
chrislema
178
15k
Designing with Data
zakiwarfel
96
4.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
20
1.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
From Idea to $5000 a Month in 5 Months
shpigford
378
45k
GraphQLとの向き合い方2022年版
quramy
33
12k
Web development in the modern age
philhawksworth
203
10k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
Making Projects Easy
brettharned
109
5.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
46k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
19
6.9k
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での議論が面白いので ぜひ読んでね!