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
7
3k
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
Kyoto.go #50 LT
https://kyotogo.connpass.com/event/313309/
utagawa kiki
April 28, 2024
Tweet
Share
More Decks by utagawa kiki
See All by utagawa kiki
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
12k
Dive into gomock / Go Conference 2024
utgwkk
14
5k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
5
1.7k
ありがとう、create-react-app
utgwkk
4
10k
mockgenによるモック生成を高速化するツール bulkmockgenのご紹介 / Kyoto.go #43
utgwkk
2
2.2k
SPAでもデータをURLでシェアしたい / Kyoto.js 19
utgwkk
2
1.8k
prototype大全 / YAPC::Kyoto 2023
utgwkk
1
4.3k
なんでもPull Requestにする / Kichijoji.pm 31
utgwkk
3
6.2k
インプットとアウトプットのサイクルを回す暮らし / Kichijoji.pm 29
utgwkk
1
9k
Other Decks in Programming
See All in Programming
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
1.8k
Why Jakarta EE Matters to Spring - and Vice Versa
ivargrimstad
0
1k
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
現場で役立つモデリング 超入門
masuda220
PRO
15
3.2k
.NET のための通信フレームワーク MagicOnion 入門 / Introduction to MagicOnion
mayuki
1
1.3k
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.4k
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
470
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
330
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
140
Arm移行タイムアタック
qnighy
0
290
Featured
See All Featured
Gamification - CAS2011
davidbonilla
80
5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
YesSQL, Process and Tooling at Scale
rocio
169
14k
It's Worth the Effort
3n
183
27k
Ruby is Unlike a Banana
tanoku
97
11k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Scaling GitHub
holman
458
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
370
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
Building Adaptive Systems
keathley
38
2.3k
Embracing the Ebb and Flow
colly
84
4.5k
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アプリケーションという立場から見ると カリカリチューニングが必要になっていないならまだいける 台数を並べればパフォーマンスを稼げる 可観測性が高いほうがメリットが大きい 他のプログラミング言語には当然スタックトレースがある
まとめ やっぱりスタックトレース欲しいやん みなさまはどのようにエラーと向き合っていますか?