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
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
例外はスローするなリターンし ろ
Search
Nakano as a Service
October 30, 2024
Programming
92
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
例外はスローするなリターンし ろ
Nakano as a Service
October 30, 2024
More Decks by Nakano as a Service
See All by Nakano as a Service
StripeとNotion、AIで作る決済自動化の裏側
nakanoasaservice
0
26
TypeScript type challengesを解いてみよう
nakanoasaservice
0
160
Hasuraにコントリビュートした話
nakanoasaservice
0
75
Other Decks in Programming
See All in Programming
AWS DevOps Agentで インシデント対応をAIに任せたい
honmarkhunt
7
2.6k
ハーネス設計入門 〜プロンプト、コンテキストの次〜
kinopeee
55
36k
From 6 People Classroom Meetup to 100 People Regional Conference / FOSS4G Hiroshima 2026
furukawayasuto
0
120
AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI
tomoyakitaura
4
1.1k
AIとGame Jamで、ゲームを完成させた話
takahirosaeki
0
110
Kiroで創り、AgentCoreで繋ぐ!AWSで実践する「AI-DLC」から「AIエージェント統合」までの最新地図
licux
3
380
個人開発基盤をまるごとCloudflareに引っ越して爆速で総合的体験を向上させた話
tinykitten
0
140
Press start. Python's next generation.
willingc
PRO
3
320
WebMCP Challenge に星空観察アプリで参加した話
okajun35
0
110
AIは賢い。でも実行環境は? CLIおじさんがAI時代に伝えたいこと ~ CLIおじさんがAI時代に伝えたいこと ~
curekoshimizu
1
190
デプロイ直後のレイテンシスパイクを調べたら、 Railsの仕様にたどり着いた
nhsykym
0
110
Webの地図
yosuke_furukawa
PRO
3
2.8k
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
28
2.8k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
520
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
450
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
380
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.7k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
820
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
6.2k
Transcript
例外はスローするなリターンし ろ
皆さん例外処理ちゃんとやってますか? 例: トークンの中身をパースして返す ついつい例外処理をサボりがち そんなあなたに function verifyToken(token: string): UserSessionInfo {
if (!isTokenValid(token)) { throw new Error("token is not valid") } return parseToken(token) } const session = verifyToken(cookie().token) /* 不正なトークンが渡ってきた場合が考慮できてない! */ const user = getUser(session.userId) // ここまでたどり着かない
例外はリターンしましょう
メリット1: 例外処理をしないと値を使えなくなる Error でないことを確かめないと userId に使えない! function verifyToken(token: string): UserSessionInfo
| Error { if (!isTokenValid(token)) { // 例外をリターンするようにした return new Error("token is not valid") } return parseToken(token) }
メリット1: 例外処理をしないと値を使えなくなる エラー処理をちゃんとすれば値を使える! function verifyToken(token: string): UserSessionInfo | Error {
if (!isTokenValid(token)) { // 例外をリターンするようにした return new Error("token is not valid") } return parseToken(token) } const session = verifyToken(cookie().token) if (session instanceof Error) { // エラーを処理する redirect("/login") return } // userId が使える! const user = getUser(session.userId)
メリット2: どんなエラーが起こるのかわかる 独自の例外クラスを定義しておけば、関数の返り値の型を見るだけでどんなエラーが起こるのかわかる 皆さんもエラーをリターンしてみてください! // 独自の例外クラスを定義 class InvalidTokenError extends Error
{} class InvalidPayloadError extends Error {} // 関数の返り値の型を見ればどんなエラーが起こるかわかる function verifyToken(token: string): UserSessionInfo | InvalidTokenError | InvalidPayloadError { if (!isTokenValid(token)) { return new InvalidTokenError() } // トークンのパースでもエラーが発生する場合 const payload = parseToken(token) if (payload instanceof Error) { return new InvalidPayloadError() } }
え、独自の例外クラスをいちいち定義するのがめんど くさい?
判別可能なエラー型で例外クラスの定義をサボる 独自の例外クラスを定義せずとも code で区別できるエラーを定義できる 以下のように使う function verifyToken(token: string): UserSessionInfo |
PubErr<"INVALID_TOKEN", string> | PubErr<"INVALID_PAYLOAD"> { if (!isTokenValid(token)) { return new PubErr({ code: "INVALID_TOKEN", cause: token }) } const payload = parseToken(token) if (payload instanceof Error) { return new PubErr({code: "INVALID_PAYLOAD" }) } return payload } const session = verifyToken(cookie().token) if (session instanceof PubErr) { if (session.code === "INVALID_TOKEN") { // PubErr<"INVALID_TOKEN"> 型として扱われる const token = session.cause // cause に原因となったtoken (string )が入っている }
判別可能なエラー型って何? 近々記事を書く予定なので詳しいことは中野に聞いてください。 とりあえず code でエラーが区別できるようになるやつと覚えていただけるとありがたいです。 定義は以下 interface PubErrProps<C extends string,
E = never> { code: C; message: string; cause?: E; } export class PubErr<C extends string, E = never> extends Error { code: C; cause!: E; constructor({ code, message, cause }: PubErrProps<C, E>) { super(message, { cause }); this.code = code; } }
え、呼び出し側でいちいち例外処理するのがだるい? function verifyToken(token: string): UserSessionInfo | PubErr<"INVALID_TOKEN", string> | PubErr<"UNEXPECTED_PAYLOAD">
{ // isValidToken がエラーをリターンするvalidateToken に変わった const validToken = verifyToken(token) if (validToken instanceof Error) { return new PubErr({ code: "INVALID_TOKEN", cause: token }) } const payload = parseToken(validToken) if (payload instanceof Error) { return new PubErr({code: "UNEXPECTED_PAYLOAD" }) } return payload }
Neverthrow のsafeTry を使う if 文が不要になった(代わりに見たこともないような構文が増えた) 。かなり端折った説明なので雰囲気だけ捉 えてほしい。 他にも便利な機能があるのでNeverthrow の公式ドキュメントを見てみてください Neverthrow
公式ドキュメント Neverthrow は新しい概念がそこそこあるのでチームでやるときはオンボーディングを丁寧にしてください。 function verifyToken(token: string) { return safeTry(function*() { const validToken = yield* verifyToken(token) // if 文は不要! const payload = yield* parseToken(validToken) // if 文は不要! return ok(payload) }) }
まとめ 例外をリターンすることで以下のメリットがある 呼び出し元に例外処理を強制できる どんなエラーが起こるのか型を見ればわかる 最初からすべてを実践する必要はない 1. Error をリターンする 2. 独自例外クラスを定義する
3. 判別可能なエラー型で独自例外クラスの定義をサボる 4. Neverthrow で呼び出し元の例外処理を端折る 補足: 返り値の型は推論されるので書かなくていい みんなも例外をリターンしてみてね!