$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
例外を投げるな、値を返せ
Search
okuzawats
March 31, 2023
Programming
9
8.1k
例外を投げるな、値を返せ
DroidKaigi.collect{ #1@Tokyo }(2023年3月31日)での発表資料です。
okuzawats
March 31, 2023
Tweet
Share
More Decks by okuzawats
See All by okuzawats
Androidアプリのモジュール分割における:x:commonを考える
okuzawats
1
420
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
370
カンファレンス参加をいかに正当化するか
okuzawats
0
310
「勉強になった」で終わらせない、ストロングスタイルの勉強会
okuzawats
0
410
10年モノのAndroidアプリのコード品質を改善していく、3つの取り組み
okuzawats
0
1.3k
Androidアプリ開発におけるSonarCloudの活用
okuzawats
0
1.2k
何故、UseCaseは1メソッドなのか
okuzawats
3
2.1k
GitHub ActionsでAndroidアプリのテストを回しまくってたら全プロジェクトのCI/CDが完全停止する寸前だった件
okuzawats
0
640
Kotlinのifを愛でる
okuzawats
0
830
Other Decks in Programming
See All in Programming
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
650
[堅牢.py #1] テストを書かない研究者に送る、最初にテストを書く実験コード入門 / Let's start your ML project by writing tests
shunk031
11
6.3k
堅牢なフロントエンドテスト基盤を構築するために行った取り組み
shogo4131
3
690
社内オペレーション改善のためのTypeScript / TSKaigi Hokuriku 2025
dachi023
1
130
How Software Deployment tools have changed in the past 20 years
geshan
0
25k
30分でDoctrineの仕組みと使い方を完全にマスターする / phpconkagawa 2025 Doctrine
ttskch
3
640
251126 TestState APIってなんだっけ?Step Functionsテストどう変わる?
east_takumi
0
280
Building AI Agents with TypeScript #TSKaigiHokuriku
izumin5210
5
1.1k
DSPy Meetup Tokyo #1 - はじめてのDSPy
masahiro_nishimi
1
110
なあ兄弟、 余白の意味を考えてから UI実装してくれ!
ktcryomm
10
9.5k
AIコードレビューがチームの"文脈"を 読めるようになるまで
marutaku
0
210
モデル駆動設計をやってみよう Modeling Forum2025ワークショップ/Let’s Try Model-Driven Design
haru860
0
210
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
40
2.2k
Automating Front-end Workflow
addyosmani
1371
200k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Visualization
eitanlees
150
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
Git: the NoSQL Database
bkeepers
PRO
432
66k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.8k
Scaling GitHub
holman
464
140k
Facilitating Awesome Meetings
lara
57
6.6k
BBQ
matthewcrist
89
9.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Stop Working from a Prison Cell
hatefulcrawdad
273
21k
Transcript
例外を投げるな、値を返せ DroidKaigi.collect{ #1@Tokyo }
話している人 • 奥澤(@okuzawats) • Chatwork株式会社(2022年9月〜) • ビジネスチャット「Chatwork」Android版のアーキテクチャ改善業、技術負債返済業をやっています。 • 好きなKotlinのスコープ関数はwithです。
今日話したいこと • 例外を投げるべきでない100の理由 • 例外を投げる代わりに値を返す、たったひとつの冴えたやり方
例外は2種類に分けられる。 • 回復不能な例外 • 回復可能な例外
例外は2種類に分けられる。 • 回復不能な例外 • 回復可能な例外←
例外を投げるべきでない100の理由 1. 参照透過性が失われる 2. 型安全でない • 型は例外について何も語らない • コンパイラも例外の処理を呼び出し元に強制しない (Paul
Chiusano, Rúnar Bjarnason, (2015)) 👉例外を投げる代わりに値を返すようにする。
None
͜͏͍͏͜ͱΛݴ͍͍ͨͷͰͳ͍ ݹ͖ྑ͖C-style🕺
例外を投げる代わりに値を返す、 たったひとつの冴えたやり方
正常・異常の直和を表現できる型を使う 1. 独自の型を定義する 2. `kotlin.Result<T>` を使う Kotlin 1.3〜。Kotlinを使っていれば使えるのがメリット。 3. `arrow.core.Either<Throwable,
T>` を使う 高機能。arrow-ktを入れる必要があるのがデメリット。
kotlin.Result<T>
arrow.core.Either<Throwable, T>
所感 1. `arrow.core.Either<Throwable, T>` は、例外の型も関数のシグネチャに含められる点が強い。`kotlin.Result<T>` はそれができない分少し弱い。 2. とはいえ、`arrow.core.Either<Throwable, T>` はarrow-ktの一機能に過ぎず、arrow-ktを入れるとそれ以外にも大量に入ってしまう。
3. 関数型に目覚めるのでなければ `kotlin.Result<T>` で済ませるか、必要最小限の機能を持ったEitherを自分で書くくらいが落としどころかもしれない(そんなに難しいことではない)。
まとめ 1. 回復可能な例外は値を返したい 2. 値を返すと言っても、 `return -1` ではない 3. 正常・異常を直和で表現できる型を使う
4. 独自に型を定義してもいいが、既に存在する `kotlin.Result<T>` や `arrow.core.Either<Throwable, T>` を使う手もある
参考文献 1. arrow.core.Either, retrieved from https://arrow-kt.io/docs/apidocs/arrow-core/arrow.core/-either/ 2. kotlin.Result, https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/ 3.
Paul Chiusano, Rúnar Bjarnason, (2015), Scala関数型デザイン&プログラミング, インプレス 4. Keishin Yokomaku, (2023), KotlinでEitherしたい, retrieved from https://speakerdeck.com/keithyokoma/either-in-kotlin