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
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しい...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
utagawa kiki
April 28, 2024
Programming
4.4k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
Kyoto.go #50 LT
https://kyotogo.connpass.com/event/313309/
utagawa kiki
April 28, 2024
More Decks by utagawa kiki
See All by utagawa kiki
メソッドのジェネリクスでGoの夢は広がるか? / Kyoto.go #65
utgwkk
2
1.8k
new(1.26) ← これすき / kamakura.go #8
utgwkk
0
5k
tparseでgo testの出力を見やすくする
utgwkk
2
2.6k
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
4
3k
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
3.7k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
4.6k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
18k
Dive into gomock / Go Conference 2024
utgwkk
14
8.8k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.8k
Other Decks in Programming
See All in Programming
Snowflake Openflow Connector利用の勘所 / 20261024developersio2026tokyo-snowflake-openflow
kasacchiful
PRO
0
260
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.7k
クラウドゲーミングのパフォーマンス最適化に挑む / Cloud Gaming Performance Tuning
vivion
0
310
全ての永続トークンを、生まれる前に消し去りたい!
sylph01
3
1.6k
Kotlinの15年とServer-Side Kotlin
n_takehata
1
190
Getting Started with Vibe Coding
miccheng
0
140
動画プレイヤーはなぜカクつくのか 〜Flutterのレンダリングとネイティブの境界を解剖する〜
naruogram
0
320
Spec-driven Development with AI
simas
PRO
0
2.2k
Long Living Tokens, Die, Die, Die! (or: The One Ring is Banned in Modern)
sylph01
0
400
AI駆動開発4年目の現在地(『あなたはFDEになるべきか?』イベント資料)
kumaiu
0
110
[Dev Group Paris Octobre 26] Agentforce, SIforce, Claudeforce, Slackbot… on s'y retrouve ?
nabondance
0
120
プロジェクトコードをキレイキレイしよう!暗黙的な参照を読み解く静的解析
ostk0069
0
200
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
780
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.6k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
650
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.2k
[SF Ruby Conf 2025] Rails X
palkan
3
1.5k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
380
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.4k
Mobile First: as difficult as doing things right
swwweet
225
10k
Testing 201, or: Great Expectations
jmmastey
46
8.4k
Practical Orchestrator
shlominoach
192
12k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
510
Transcript
Go製Webアプリケーションの エラーとの向き合い方大全 あるいは やっぱりスタックトレース欲しいやん Kyoto.go #50 @utgwkk (うたがわきき)
自己紹介 @utgwkk (うたがわきき) 株式会社はてな Webアプリケーションエンジニア in 京都 最近はGoを書いて暮らしています
ここで宣伝 Go Conference 2024 (6/8) で登壇します Dive into gomockというタイトルでやります 渋谷で会いましょう
まったく関係ない宣伝 アイコンのステッカー配っています
アンケート Goでエラーハンドリングをしたことがある? (ここで挙手を促す)
前提 Go製Webアプリケーション GraphQL API (gqlgen) + REST API
Goのエラーといえば? if err != nil { return nil, err }
return errors.New("not found") return fmt.Errorf("failed to fetch: %w", err)
課題感 return nil, err どこで発生したエラーなのか分からない そうして、向き合いが発生したのであった こうやって向き合っているよ〜という歩みと現状を紹介
fmt.Errorf でラップする return fmt.Errorf("failed to fetch: %w", err) メッセージを都度考える必要がある どこで発生したエラーなのか一意に定まらない
(grepしたらいけるけど)
golang.org/x/xerrors を使う時代 スタックトレース付きでエラーを返せる return xerrors.Errorf("failed to fetch: %w", err) ほぼ非推奨になっているパッケージを使いつづけることへの不安
(Errorfはdeprecated解除された) メッセージを都度考える必要があるのには変わりがない xerrors.Errorf(": %w", err) というイディオムがあるにはあるが
panicを使う……? package main func main() { doSomething() } func doSomething()
{ panic("failed!!") }
panicを使う……? panic: failed!! goroutine 1 [running]: main.doSomething(...) /tmp/sandbox423004243/prog.go:8 main.main() /tmp/sandbox423004243/prog.go:4
+0x25
panicを使う……? panicしたらスタックトレースが載る!! けっこう真面目に考えたこともあったけど却下 Goの標準的なエラーハンドリング方法から大きく外れる どこからエラーが返ってくるのか予測不能になる
オレオレライブラリでスタックトレースを載せる return errwithframe.New(err) xerrorsの実装を真似る Errorメソッドでスタックトレースを出力する いったんこれで落ち着いている 世間にあるライブラリを使ったほうがいいかも? (後述します)
スタックトレースの時代が来ている 各社で事例あり Go言語のAPIサーバーの冗長なエラーログを40%削減した話 #LayerXテック アドカレ - LayerX エンジニアブログ UbieにおけるGo言語のエラーハンドリング
エラーハンドリングへの関心が高まっている https://findy.connpass.com/event/314417/
Goのエラーがスタックトレースを含まない理由 Goのerrorがスタックトレースを含まない理由 - methaneのブログ そういう思想や宗教ではなく慎重に調整している パフォーマンスの低下はそうですね
エラーのスタックトレースの歴史 https://speakerdeck.com/sonatard/go-error-trace
Webアプリケーションという立場から見ると カリカリチューニングが必要になっていないならまだいける 台数を並べればパフォーマンスを稼げる 可観測性が高いほうがメリットが大きい 他のプログラミング言語には当然スタックトレースがある
まとめ やっぱりスタックトレース欲しいやん みなさまはどのようにエラーと向き合っていますか?