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
180
Google Cloud のモニタリング製品を徹底活用してみた
karszawa
0
120
ダウンタイム 30 秒で AlloyDB に移行した話
karszawa
0
590
DMS で AlloyDB に簡単移行!
karszawa
0
130
【現場の本音】App Engine から Cloud Run に移行してみた
karszawa
0
250
cls-hooked による実行コンテキストの保存と利用
karszawa
0
1.1k
Hasura の Relationship と権限管理
karszawa
0
1.1k
Other Decks in Programming
See All in Programming
Vue Fes Japan 2026 タイムテーブル徹底解説
448jp
1
630
phperだってパンチカードでコーディングしたい
o0h
PRO
0
230
最近”作らせてる” ローカルAIアプリの話
akit37
0
200
[2026-09-26]空論ジェネリックプロセス~テスト資産とAIで紡ぐ、再現可能なパフォーマンスチューニングの話~
tosite
0
260
ジョジョの世界をXRで再現する
mofurune
0
130
パズルゲームの作り方 / how to make puzzle games
kaityo256
PRO
2
270
C#の現在地 進化の歴史と、AI時代の.NET Everywhere
neuecc
5
4.9k
Vue Fes Japan の “作る側”に関わってみて
naokihaba
0
130
Kubernetes祭り #2 OP/ED
bells17
0
100
半永久的に提供し続けられるプライベートクラウドを目指して ― 利用者の認知負荷を抑えるAPI抽象化とハードウェア世代交代の基盤設計
tomokon
0
460
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
780
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
170
Featured
See All Featured
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
570
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
Exploring anti-patterns in Rails
aemeredith
4
520
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
12k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
WENDY [Excerpt]
tessaabrams
14
40k
30 Presentation Tips
portentint
PRO
1
420
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
270
Art, The Web, and Tiny UX
lynnandtonic
304
22k
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 で募集中!