Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
DomainException と Result 型で作る型安全なエラーハンドリング
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Hiroaki KARASAWA
March 28, 2025
Programming
1.6k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
DomainException と Result 型で作る型安全なエラーハンドリング
noren.ts #1
Hiroaki KARASAWA
March 28, 2025
More Decks by Hiroaki KARASAWA
See All by Hiroaki KARASAWA
スタートアップでポストモーテムを4年で200回やって得た学び
karszawa
1
170
成功する技術選定について
karszawa
2
3.3k
飲食店のインフラサービス “ダイニー” のトラブル対応のすべて
karszawa
0
190
Google Cloud のモニタリング製品を徹底活用してみた
karszawa
0
120
ダウンタイム 30 秒で AlloyDB に移行した話
karszawa
0
600
DMS で AlloyDB に簡単移行!
karszawa
0
140
【現場の本音】App Engine から Cloud Run に移行してみた
karszawa
0
250
cls-hooked による実行コンテキストの保存と利用
karszawa
0
1.1k
Hasura の Relationship と権限管理
karszawa
0
1.2k
Other Decks in Programming
See All in Programming
TanStack Vue Query と Pinia Colada から学ぶ非同期状態の型設計
aoshi
0
620
現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜
siroemk
2
1.2k
AIがコードを書いてくれる時代、我々は何を確かめるのか
yosuke_furukawa
PRO
13
5.7k
クラウドゲーミングのパフォーマンス最適化に挑む / Cloud Gaming Performance Tuning
vivion
0
330
Spec-driven Development with AI
simas
PRO
0
2.3k
graphql-ruby を Spinel で速くしようとした話
mtsmfm
0
140
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
160
エージェントを使い続けるためのメタワーク / Meta-work for keeping using the agent
rkaga
6
2.2k
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.8k
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
600
Railsバージョンを4倍にした話
optim
0
940
Distance field of Julia set
kinakomoti321
0
280
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
My Coaching Mixtape
mlcsv
0
380
Balancing Empowerment & Direction
lara
6
1.4k
Exploring anti-patterns in Rails
aemeredith
4
560
How to Talk to Developers About Accessibility
jct
2
610
Automating Front-end Workflow
addyosmani
1370
210k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.9k
GraphQLとの向き合い方2022年版
quramy
50
15k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
620
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.9k
A designer walks into a library…
pauljervisheath
211
25k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
740
Transcript
© 2025 Dinii Inc. DomainException と Result 型で作る 型安全なエラーハンドリング noren.ts
#1 2025-03-28 Hiroaki KARASAWA
株式会社 ダイニー © 2025 Dinii Inc. ※こちらの枠内に詳細や、画像を記載/貼り付けしてください。 白枠は、必要に応じて消していただいても大丈夫です。 @karszawa Introduction
Hiroaki KARASAWA (karszawa) 株式会社ダイニー VP of Technology Google Champion Innovator → Google Developer Experts (Modern Architecture, Serverless Application, Data) 趣味: HUNTER×HUNTER 自己紹介
株式会社 ダイニー © 2025 Dinii Inc. 01 02 03 04
05 ダイニーの事業・技術・プロダクトについて JavaScript のエラーを二種類に分類 DomainException & Result 型について紹介 サードパーティーライブラリと比較 総括 資料名を記載
株式会社 ダイニー © 2025 Dinii Inc. ダイニーの事業・技術・プロダクトについて 01 資料名を記載
株式会社 ダイニー © 2024 Dinii Inc. 飲食店の売上UPに貢献する唯一無二のスーパーモバイルPOS オペレーションなしで 売上UP! AIと専属スタッフにお任せ
お客様を 自動で会員化 自動販促 メッセージ アンケート 自動回収 店員への チップ/投げ銭 圧倒的な 使いやすさで 客単価UP ロイヤルティ プログラム 顧客情報を 接客に活用
ダイニーが目指すのは、 ダイニーについて 株式会社ダイニー | Company Deck for Product © 2025
Dinii Inc.
TypeScript, React による言語・フレームワークの統一 ダイニーについて 複数プロダクトを跨った機能修正でも、一つのチームで担当することができる 株式会社ダイニー | Company Deck for
Product © 2025 Dinii Inc.
株式会社 ダイニー © 2025 Dinii Inc. ダイニーについて 計測してみた。 ※ TypeScript
のコードのみを計測 ※ 自動生成コードを除外 バックエンドコードベースの規模を紹介します。 3,000 files 340,000 lines ⛰ 2020年からの積み重ね ⛰
本日のトピック
TypeScript のエラーハンドリングを極める
良いね…
株式会社 ダイニー © 2025 Dinii Inc. ダイニーについて 資料名を記載 下記の点に注意して発表をお聞きください。 1.
NestJS のバックエンドサービス 2. 普通の HTTP Web サーバー 3. 2020年頃 の意思決定が色濃く反映されている 4. クライアントのエラーハンドリングは懇親会で話そうね Disclaimer
株式会社 ダイニー © 2025 Dinii Inc. JavaScript のエラーを二種類に分類 02 資料名を記載
株式会社 ダイニー © 2025 Dinii Inc. 資料名を記載 JavaScript のエラーを分類 注文
→ 在庫確認 👀 → 在庫なし 🫥 → エラー! 🚨 何かしらの異常なので全く発生しないのが期待値 サードパーティー製のライブラリも基本的にこの形式でエラーを返し てくる…。 1) ランタイムエラー システムエラーではないが、ユーザー体験に悪影響の可能性 一定数は発生が想定される。 2) ビジネスロジックのエラー
株式会社 ダイニー © 2025 Dinii Inc. JavaScript のエラーを分類 資料名を記載 e.g.
Node.js 自体のメモリリーク もはや TypeScript は関係ない ベストプラクティス • ちゃんとヘルスチェックを実装して怪しいやつはどんどん kill していこう • kill を監視して Profiler で分析しよう Node.js に詳しいお兄さんたちに聞いてみよう もう一つのエラー = 処理系のエラー (Fatal Error)
株式会社 ダイニー © 2025 Dinii Inc. JavaScript のエラーを分類 資料名を記載 独自実装部分は
TypeScript を真面目に活用すればほぼ抑制できる 問題はサードパーティー製のライブラリが throw するエラー そもそも throw されることを関知できるデザインになっていない IMO: 真面目に対処することを前提とせず(無理なので)、大域での error handelr を基本とするべき ※ もちろん発生が予期されるもの、頻発するものは真面目に try-catch したら良い 1) ランタイムエラーの対処
株式会社 ダイニー © 2025 Dinii Inc. JavaScript のエラーを分類 資料名を記載 ここが本日の本題
言いたいこと とにかく throw するな 2) ビジネスロジックのエラー
株式会社 ダイニー © 2025 Dinii Inc. JavaScript のエラーを分類 資料名を記載 とにかく
throw するな → throw した時点で型情報が失われてしまう 型情報が残っていると何が嬉しいか → エラーの対処を強制するコードベースデザインが可能になる ダイニーでは DomainException というクラスを利用している → が、とにかく throw しなければ何でも良いと思っている ※ エラーではなく「例外 – Exception」と呼ぶ(ただの決めの話) ビジネスロジックのエラーのベストプラクティス
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
03 資料名を記載
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 DomainException という基底クラスを継承した例外種別ごとに別々のクラス(ダイニー独自実装) DomainException とは?
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 1) 基底クラスで具象クラスをすべてハンドリングできるから なぜクラスなのか?
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 2) 追加情報を付与できるから なぜクラスなのか?
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 1) 実際の例外が発生している箇所で new する 具体的な使い方
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 1) エラーをハンドリングしたい任意の箇所 or リクエストハンドラーでハンドリングする 具体的な使い方 リクエストハンドラー ドメインロジックの どこか
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 instanceof DomainException を利用した徹底したハンドリング 徐々に型が 絞り込まれる
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 人間たまには throw したくなる バグでしかそうならないとき • 何かおかしなことが起こっているのでそこで止めたい = ランタイムエラーと同様に扱う • 基本的には型的にハンドリングしたいがそう上手くいかないときもあるよね 逆に throw する場合
株式会社 ダイニー © 2025 Dinii Inc. DomainException & Result 型
資料名を記載 TypeScript には union があるので Result, Either 的な概念が無くても良いが… すべてのエラーをハンドリングするまで型補完が効かないので使用感が悪い が、これも TypeScript 4.x の時代の話なので今は良い感じに補完してくれるのかも… Result 型 – 「正常値」か「エラー」を返すことを表現 union を使う場合
株式会社 ダイニー © 2025 Dinii Inc. エラーハンドリング 型定義 DomainException &
Result 型 資料名を記載 Result 型でプログラミングの見通しを良くする Result 型は 多くのプログラミング言語で ネイティブサポートされている
株式会社 ダイニー © 2025 Dinii Inc. サードパーティーライブラリと比較 04 資料名を記載
株式会社 ダイニー © 2025 Dinii Inc. サードパーティーライブラリと比較 資料名を記載 実はサードパーティーの似たようなライブラリがある。 サードパーティーライブラリとの比較
株式会社 ダイニー © 2025 Dinii Inc. サードパーティーライブラリと比較 資料名を記載 NeverThrow かな?
シンプルなため一定のルールは必要そう(例: err をネストしない)。 元の実装も1000行程度なので、独自のフレームワーク等と組み込みたいなら独自実装もぜんぜんアリ TypeScript の進化で工夫が要らなくなった。 ありがとう TypeScript 💖 2025年からプロジェクトを始めるなら…(IMO)
株式会社 ダイニー © 2025 Dinii Inc. まとめ 資料名を記載 ダイニーでは DomainException
+ Result 型で型安全なバックエンドを構築しています。 2020年当時としては良い判断だったと思いますが、 今はサードパーティの良い感じのライブラリを使うこともできます。 ともかく コミュニティのデフォルトとして Error を throw というのが辛い。 ので、勉強会でエラーハンドリングについて語って JS コミュニティを一ミリでも動かしたい。 まとめ
株式会社 ダイニー © 2025 Dinii Inc. まとめ 資料名を記載 事業会社のソフトウェアエンジニアに役立つ情報をほぼ毎日発信しています。 X
発信強化中! 『dinii karasawa』で検索 フォローしてね!
株式会社 ダイニー © 2025 Dinii Inc. まとめ 資料名を記載 #noren_ts でご質問ください!
質問は X で募集中!