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
例外はスローするなリターンし ろ
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
初心者DevRelとして参加者だった私が、DevRel Talks!#2に登壇するまでにしてきたこと
sokohirai
0
370
iOSDC Japan 2026 - Swiftで作って学ぼう!データベース自作入門
kaseken
2
140
AgentCore CLI で進化した AWS での AI エージェントの作り方 : 必要な機能を必要な時に
icoxfog417
PRO
3
330
思考垂れ流し開発 ~音声入力 × AIエージェント × 開発ハーネスによる試行錯誤~
npostring
0
1.1k
JPUG勉強会 OSSデータベースの内部構造を理解しよう(第2回)
oga5
0
120
AI に Inclusive UI を書かせよう — Design Rules Skill で Compose UI を作り直す
theoriatec2024
1
470
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
450
Jetpack Compose メカニズム
skydoves
0
140
モバイル交通系ICへのチャージ実例から考える、クロスプラットフォーム開発におけるiOS実機テスト設計とCI運用
yusuga
1
430
AIは賢い。でも実行環境は? CLIおじさんがAI時代に伝えたいこと ~ CLIおじさんがAI時代に伝えたいこと ~
curekoshimizu
1
240
iOSDC2026登壇資料.pdf
riofujimon
0
120
一参加者から『中の人』へ 〜全通PHPerがブースに立って学んだ、カンファレンスを100倍楽しむコツ〜
wp_daisuke
0
140
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Raft: Consensus for Rubyists
vanstee
141
7.7k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
460
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Building Applications with DynamoDB
mza
96
7.2k
It's Worth the Effort
3n
188
29k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
270
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Amusing Abliteration
ianozsvald
1
290
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 で呼び出し元の例外処理を端折る 補足: 返り値の型は推論されるので書かなくていい みんなも例外をリターンしてみてね!