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
4.2k
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
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
1
150
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
1k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
2.3k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
15k
Dive into gomock / Go Conference 2024
utgwkk
14
7.6k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.6k
ありがとう、create-react-app
utgwkk
4
11k
mockgenによるモック生成を高速化するツール bulkmockgenのご紹介 / Kyoto.go #43
utgwkk
2
2.4k
SPAでもデータをURLでシェアしたい / Kyoto.js 19
utgwkk
2
1.9k
Other Decks in Programming
See All in Programming
Microsoft Orleans, Daprのアクターモデルを使い効率的に開発、デプロイを行うためのSekibanの試行錯誤 / Sekiban: Exploring Efficient Development and Deployment with Microsoft Orleans and Dapr Actor Models
tomohisa
0
220
あのころの iPod を どうにか再生させたい
orumin
2
2.5k
LLMOpsのパフォーマンスを支える技術と現場で実践した改善
po3rin
8
990
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
MLH State of the League: 2026 Season
theycallmeswift
0
170
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
180
AIコーディングAgentとの向き合い方
eycjur
0
240
UbieのAIパートナーを支えるコンテキストエンジニアリング実践
syucream
2
770
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
Infer入門
riru
4
1.6k
DockerからECSへ 〜 AWSの海に出る前に知っておきたいこと 〜
ota1022
5
1.8k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
BBQ
matthewcrist
89
9.8k
Building an army of robots
kneath
306
46k
The Invisible Side of Design
smashingmag
301
51k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Producing Creativity
orderedlist
PRO
347
40k
It's Worth the Effort
3n
187
28k
Building Applications with DynamoDB
mza
96
6.6k
Scaling GitHub
holman
463
140k
Thoughts on Productivity
jonyablonski
69
4.8k
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アプリケーションという立場から見ると カリカリチューニングが必要になっていないならまだいける 台数を並べればパフォーマンスを稼げる 可観測性が高いほうがメリットが大きい 他のプログラミング言語には当然スタックトレースがある
まとめ やっぱりスタックトレース欲しいやん みなさまはどのようにエラーと向き合っていますか?