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
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しい...
Search
utagawa kiki
April 28, 2024
Programming
4.3k
7
Share
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
new(1.26) ← これすき / kamakura.go #8
utgwkk
0
3.7k
tparseでgo testの出力を見やすくする
utgwkk
2
1.5k
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
4
2k
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
2.7k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
4.3k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
17k
Dive into gomock / Go Conference 2024
utgwkk
14
8.6k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.7k
ありがとう、create-react-app
utgwkk
4
12k
Other Decks in Programming
See All in Programming
ハーネスエンジニアリングとは?
kinopeee
13
6.3k
煩雑なSkills管理をSoC(関心の分離)により解決する――関心を分離し、プロンプトを部品として育てるためのOSSを作った話 / Solving Complex Skills Management Through SoC (Separation of Concerns)
nrslib
4
1k
Programming with a DJ Controller — not vibe coding
m_seki
3
470
AIと共に生きる技術選定 2026
sgash708
0
110
[RubyKaigi 2026] Require Hooks
palkan
1
240
Back to the roots of date
jinroq
0
520
レガシーPHP転生 〜父がドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜
panda_program
0
1.1k
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
16
5.6k
AWSコミュニティ活動は顧客のクラウド推進に効くのか / Do AWS community activities help customers adopt the cloud?
seike460
PRO
0
150
セグメントとターゲットを意識するプロポーザルの書き方 〜採択の鍵は、誰に刺すかを見極めるマーケティング戦略にある〜
m3m0r7
PRO
0
600
Server-Side Kotlin LT大会 vol.18 [Kotlin-lspの最新情報と Neovimのlsp設定例]
yasunori0418
1
200
検索設計から 推論設計への重心移動と Recall-First Retrieval
po3rin
4
1.2k
Featured
See All Featured
The SEO identity crisis: Don't let AI make you average
varn
0
450
Game over? The fight for quality and originality in the time of robots
wayneb77
1
160
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
180
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
900
How to Think Like a Performance Engineer
csswizardry
28
2.6k
Building an army of robots
kneath
306
46k
Google's AI Overviews - The New Search
badams
0
990
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.2k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
170
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
190
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
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アプリケーションという立場から見ると カリカリチューニングが必要になっていないならまだいける 台数を並べればパフォーマンスを稼げる 可観測性が高いほうがメリットが大きい 他のプログラミング言語には当然スタックトレースがある
まとめ やっぱりスタックトレース欲しいやん みなさまはどのようにエラーと向き合っていますか?