Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
例外はスローするなリターンし ろ
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Nakano as a Service
October 30, 2024
Programming
89
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
24
TypeScript type challengesを解いてみよう
nakanoasaservice
0
150
Hasuraにコントリビュートした話
nakanoasaservice
0
72
Other Decks in Programming
See All in Programming
TSKaigi Night Talks 2026_TypeScriptでサプライチェーンの整合性を型に閉じ込める
geekplus_tech
0
320
Swiftのレキシカルスコープ管理
kntkymt
0
210
コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —
ioki
0
150
LLM本来の能力を解き放つサンドボックス技術とAI民主化への適用
yukukotani
3
3.2k
net-httpのHTTP/2対応について
naruse
0
450
Spec-Driven Development with AI-Agents: From High-Level Requirements to Working Software
antonarhipov
2
470
DynamoDBには集計系のクエリがないけどなんとかしたい
musan
1
130
TypeScript+Orvalで実現する型安全かつ堅牢でスケーラブルなマルチチャネル通知基盤 / TSKaigi Night talks ~after conference~
d0riven
0
310
AI 時代のソフトウェア設計の学び方
masuda220
PRO
29
12k
Composerを使ったサプライチェーン攻撃の様子を眺めてみる #phpstudy
o0h
PRO
2
230
AIチームを指揮するOSS「TAKT」活用術 / How to Use “TAKT,” an OSS Tool for Orchestrating AI Teams
nrslib
6
840
CLIであることを活かしたGitHub Copilot CLI活用術 / GitHub Copilot CLI Pro Tips & Tricks
nao_mk2
1
1.2k
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.8k
Being A Developer After 40
akosma
91
590k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
How GitHub (no longer) Works
holman
316
150k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
The Invisible Side of Design
smashingmag
302
52k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
190
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.1k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
320
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.3k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.3k
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 で呼び出し元の例外処理を端折る 補足: 返り値の型は推論されるので書かなくていい みんなも例外をリターンしてみてね!