Goのエラーハンドリングについて考え直してみる

June 30, 2022

はじめに

別の記事 でエラーハンドリングについて方針を書きましたが,いくつか考え直した点があったのでまとめます.

要点

  • golang.org/x/xerrors パッケージではなく標準の errors パッケージを使用する.
  • 上位レイヤに返す際にはfmt.Errorf() を使用する.

使用パッケージについて

スタックトレースが必要だという理由で golang.org/x/xerrors パッケージを採用していました. しかし,以下の理由から使用するのをやめました.

  • パッケージそのものが役目を終えている
  • スタックトレースが必要ない(と考えるに至った)

パッケージそのものが役目を終えている

有名な話ですが golang.org/x/xerrors パッケージは Go 1.13 に一部機能が組み込まれ,役目を終えています. メンテナンスもされていません.

スタックトレースが必要ない

スタックトレースを出力することですべての情報を詳細に返すよりも,必要最低限の情報のみを返しログ出力をシンプルに保つほうが良いと判断しました. エラーメッセージを適切に設計するという別の問題が発生しましたが,これは経験を積みながらぼちぼち考えていこうと思います.

スタックトレースの出し方について

そもそも,pkg/errors パッケージを使用することでスタックトレースは付与できました. 後々スタックトレースが必要になった(と考えるようになった)ときにはこちらの方法を使おうと思います.

pkg/errors パッケージは,Go2 でエラーハンドリングに機能が追加されることから,機能追加を行う予定はないようですが,メンテナンスはされています.

上記の issue でもメンテナンスがされていないという指摘がありますが,バグが出る余地が少ないので改修頻度が少ないことが述べられています.

(中略) Having used this package from the very beginning one could argue its feature complete and doesn't need much maintenance.

「標準ライブラリが少なくとも pkg/errors と同等の機能を持つようになるまで使い続けるつもり」との意見もあり,積極的に使用しても良いのかもしれません.

For what it's worth I still use this package, and will continue to do so until the standard library is at least feature parity with pkg/errors.

まとめ

ひとまず Go におけるエラーハンドリングはこれで行こうと思います. 身に付けないと,と思うことは多く不安になりますが,焦らずにいきましょう.