errgroupのはまりどころと回避策
下記で示している closures and groutines の問題は Go v1.22 の for ループの挙動の変更により問題にならなくなりました🙌。詳しくはリリースノートを参照ください 。 はじめに errgroup を使うときに closures and groutines の話ではまってしまうよね、という自分向けの備忘録です。 golang.org/x/sync/errgroup golang.org/x/sync/errgroup は、複数の goroutine を実行して、それらのうちにエラーがあったときにエラーを知る、ということを可能にしてくれるライブラリです。sync.WaitGroup は実行した goroutine が終わるのを待ちますが、エラーがあったかどうかはわかりません。各 goroutine で発生したエラーを知りたければ別途処理する必要があります。err
今goのエラーハンドリングを無難にしておく方法（2021.09現在）
2021年7月現在、goでエラーハンドリングってどうやって扱うのが無難なのかについて、いろいろと調べました。 昔から人気な pkg/errors、Go公式がメンテナンスしていたxerrors、 go v1.13から追加されたfmt.Errorfなどエラーハンドリングの選択肢がいろいろとあるので、stacktrace欲しい場合とそうでない場合で個人的にベストだと思った方法をまとめました。 エラーハンドリングに求める要件 エラーが発生した箇所を追える エラーの原因によって処理を分岐する （場合による）stacktraceがみれる 結論 stacktraceが不要な場合 fmt.Errorfでラップし、errors.Isで判定する stacktraceが必要な場合 pkg/errors.Wrapでラップし、pkg/errors.Causeで判定する log.Printf("%+v", err)で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
