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
例外を投げるな、値を返せ
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
440
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
410
カンファレンス参加をいかに正当化するか
okuzawats
0
330
「勉強になった」で終わらせない、ストロングスタイルの勉強会
okuzawats
0
430
10年モノのAndroidアプリのコード品質を改善していく、3つの取り組み
okuzawats
0
1.3k
Androidアプリ開発におけるSonarCloudの活用
okuzawats
0
1.3k
何故、UseCaseは1メソッドなのか
okuzawats
3
2.2k
GitHub ActionsでAndroidアプリのテストを回しまくってたら全プロジェクトのCI/CDが完全停止する寸前だった件
okuzawats
0
660
Kotlinのifを愛でる
okuzawats
0
1k
Other Decks in Programming
See All in Programming
登壇資料を作る時に意識していること #登壇資料_findy
konifar
4
1.7k
【卒業研究】会話ログ分析によるユーザーごとの関心に応じた話題提案手法
momok47
0
200
今から始めるClaude Code超入門
448jp
8
9.1k
生成AIを使ったコードレビューで定性的に品質カバー
chiilog
1
280
生成AIを活用したソフトウェア開発ライフサイクル変革の現在値
hiroyukimori
PRO
0
110
それ、本当に安全? ファイルアップロードで見落としがちなセキュリティリスクと対策
penpeen
7
4k
LLM Observabilityによる 対話型音声AIアプリケーションの安定運用
gekko0114
2
440
開発者から情シスまで - 多様なユーザー層に届けるAPI提供戦略 / Postman API Night Okinawa 2026 Winter
tasshi
0
210
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
300
IFSによる形状設計/デモシーンの魅力 @ 慶應大学SFC
gam0022
1
310
Apache Iceberg V3 and migration to V3
tomtanaka
0
170
高速開発のためのコード整理術
sutetotanuki
1
410
Featured
See All Featured
BBQ
matthewcrist
89
10k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
410
How to Talk to Developers About Accessibility
jct
2
140
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
0
150
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
86
Building an army of robots
kneath
306
46k
How STYLIGHT went responsive
nonsquared
100
6k
Mobile First: as difficult as doing things right
swwweet
225
10k
Faster Mobile Websites
deanohume
310
31k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.3k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
95
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
117
110k
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