概要
Go言語の エラーハンドリング の冗長さは長年議論されてきた課題。 Goチームとコミュニティは 様々な提案 （check/handle、try、?演算子など）を試みたが、 十分な合意 には至らなかった。 現状のエラーハンドリング方法は冗長だが、 言語仕様の変更は見送られる方針。 今後は 標準ライブラリやツールの改善 で利便性向上を目指す。 IDEやツールの進化も 冗長さの緩和 に貢献可能。
Go言語のエラーハンドリングの歴史と議論
- Go言語のエラーハンドリング は「if err != nil」パターンが多用される冗長さが課題。
- API呼び出しや単純なエラー返却が多いプログラムでは、 本質的な処理よりエラー処理が目立つ 傾向。
- 例：printSum関数の10行中6行がエラー処理となり、ノイズと感じられる。
- 長年のユーザー調査でも 「エラーハンドリングの冗長さ」 が最上位の不満事項。
Goチームによる主な提案
-
2018年：「check/handle」機構（Go 2構想）
- Marcel van Lohuizenのドラフト設計に基づく。
- 他言語との比較や代替案も詳細に分析。
- 設計が複雑すぎるとして却下。
-
2019年：「try」提案
- check/handle案を簡素化し、「try」組み込み関数を導入。
- コントロールフローの隠蔽や可読性低下が懸念され、コミュニティの反発も大きく却下。
-
2024年：「?」演算子案
- Rustの「?」演算子を参考にした提案。
- ユーザー調査では直感的な理解が得られたが、細かな修正提案や意見対立が多発し、合意に至らずクローズ。
-
その他コミュニティからも多数の提案
- Ian Lance Taylorによる「エラーハンドリング改善提案まとめ」やGo Wikiで議論を整理。
- Sean K. H. Liaoのブログなどで膨大な提案が可視化。
合意形成の難しさと現状維持の決定
- いずれの提案も 十分なコンセンサスを得られず却下。
- Goの設計思想「同じことを複数の方法で書かせない」にも合致せず。
- 新構文導入は 既存ユーザーとの分断や非互換性リスク も伴う。
- Generics導入時との違い：Genericsは使わなくても済むが、エラーハンドリング構文は全員が使う必要が生じる。
現状のエラーハンドリングと今後の方向性
- 現行の冗長なエラーハンドリングも「 実際にエラーを適切に扱う場合」はノイズが目立たない。
- エラー情報の付加（例：fmt.Errorfで詳細メッセージ追加） により、実用的なコードが書ける。
- 標準ライブラリの拡充 （例：cmp.Orで複数エラーの同時処理）による利便性向上が期待。
- IDEやLLM支援によるコード補完、エラーハンドリング部分の 表示切替機能 など、ツールによる冗長さ緩和も可能。
- デバッグ時もif文が独立していることでブレークポイント設定が容易。
結論
- エラーハンドリング構文の抜本的な変更は当面行わない 方針。
- 標準ライブラリやツールの改善、IDEの進化などで 実用性と可読性の向上 を目指す。
- Goの設計原則 とコミュニティの多様な意見を尊重した判断。