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
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
Python Lambdaにおけるテストしやすい設計とAI支援の活用 / Designing Testable Python Lambda Functions with AI
kitano_yuichi
1
300
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
160
Enforcing Your Architecture with Unit Tests in the AI Era (Swift Connection X)
steliosf
PRO
1
150
AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers
omatty198
0
360
Kotlinize Is Not Just Converting to Kotlin
chigichan24
1
220
Crash Auto Pipelines
veronikapj
1
380
SODA - FACT BOOK(EN)
sodainc
1
210
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
540
flutter_test のその先へ — Flutter アプリの LLM 機能に「評価」という品質保証を
kosukesaigusa
0
200
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
5.1k
LLM 101
dalinaum
0
470
あなたの await、OS まで届いてる? strace で覗く JavaScript の非同期
hasutosasaki
1
2.2k
Featured
See All Featured
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
970
Why Our Code Smells
bkeepers
PRO
340
58k
Color Theory Basics | Prateek | Gurzu
gurzu
1
510
The Curious Case for Waylosing
cassininazir
1
610
Game over? The fight for quality and originality in the time of robots
wayneb77
1
330
GraphQLとの向き合い方2022年版
quramy
50
15k
Typedesign – Prime Four
hannesfritz
42
3.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
53
4k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.3k
ラッコキーワード サービス紹介資料
rakko
5
5.7M
Automating Front-end Workflow
addyosmani
1370
210k
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 で募集中!