【ITニュース解説】Introducing: A Go package to reduce err boilerplate

Go言語は、そのシンプルさと高速性から多くの開発者に愛されているプログラミング言語である。並行処理が容易な点も大きな魅力の一つだ。しかし、Go言語で開発を進める中で、多くの開発者が繰り返し記述することになる、ある定型的なコードパターンが存在する。それがエラーハンドリングに関する部分だ。

Go言語では、関数の戻り値として結果とエラーを返すのが一般的である。例えば、何らかの処理を行った結果、エラーが発生したかどうかを確認するために、次のようなコードを頻繁に記述する。

if err != nil { return nil, err }

このコードは、もし処理の結果エラー（err）がnil（エラーがないことを意味する）でなければ、すぐにエラーを呼び出し元に返し、それ以降の処理を行わない、ということを示している。一つの関数内で一度だけこのコードを書くのであれば問題ないが、例えば、複数のステップを踏む処理を行う関数では、各ステップの後にこのエラーチェックのコードを何度も記述する必要が出てくる。

記事にある例では、一つのメソッドの中で15行ものコードが、ただエラーを返すためだけに増えてしまう可能性があると指摘している。このような、本質的な処理ではないにも関わらず、繰り返し記述する必要がある定型的なコードのことを、プログラミングの世界では「ボイラープレートコード」と呼ぶ。ボイラープレートコードが増えると、コード全体の行数が増加し、コードの見た目が複雑になることで可読性が低下する。本来のビジネスロジックが埋もれてしまい、コードの意図を把握しにくくなるという問題がある。また、単純なエラーチェックの記述に手間がかかるため、開発効率の低下にも繋がる。

このようなGo言語におけるエラーハンドリングのボイラープレート問題を解決するために開発されたのが、今回紹介する「to」パッケージである。このパッケージの主な目標は、「フォワードパイプ演算子」や「バインドモナド」と呼ばれるプログラミングの概念をGo言語で実現することだ。これらの概念は、複数の関数や処理をまるでパイプで繋ぐように連続して実行し、その途中でエラーが発生した場合、それ以降の処理を中断してすぐにエラーを呼び出し元に返す仕組みを指す。もし一連の処理がすべて成功すれば、最後の処理の結果が返される。これにより、開発者は各ステップでの冗長なエラーチェックの記述から解放され、より簡潔で読みやすいコードを書けるようになることを目指している。

この「フォワードパイプ演算子」のような機能を実装する際、開発者はGo言語の特性に起因するいくつかの困難に直面した。例えば、C#のようなオブジェクト指向言語では、拡張メソッドを使うことで「1.Pipe(Increment).Pipe(Increment)」のように、どんなオブジェクトにも.Pipe()というメソッドを生やして処理を数珠つなぎにすることが比較的容易だ。しかし、Go言語はオブジェクト指向言語ではないため、C#のようなアプローチはそのままでは使えない。

開発者は当初、Chainという構造体を作成し、これに.Bindメソッドを持たせて、Chainオブジェクトを連結していく方法を検討した。これは連結リストのようなイメージで、次の処理を繋いで新しいChainオブジェクトを返すというものだった。しかし、当時のGo言語では、メソッドに対してジェネリクス（様々な型を汎用的に扱える仕組み）を直接適用することができなかったため、様々な型の入力と出力を扱う汎用的なChain構造体を作成することが難しかった。

次に、Compose[T, U, V any](func(T)(U, error), fn2(U) (V, error)) func(T) (V, error)のような関数を考えるアプローチも試された。これは、複数の関数を組み合わせて新しい関数を作るもので、Bind(fn1, Bind(fn2, fn3))のように再帰的に関数を連結するイメージだ。しかし、この方法は構文が非常に複雑になり、また関数呼び出しのオーバーヘッドも無視できないという課題があった。さらに、可変引数と型アサーション（プログラム実行時に変数の型を特定する）を利用する方法も検討されたが、これにはリフレクション（プログラム実行中にプログラム自身の構造を調べたり変更したりする機能）を伴い、やはりパフォーマンス上のオーバーヘッドが懸念されたため、採用には至らなかった。

こうした試行錯誤の末にたどり着いたのが、「to」パッケージが提供するto.BindNという形だ。ここでいうNは、連結したい関数の数を表す。例えば、3つの関数を連結したい場合はto.Bind3、4つの関数ならto.Bind4のように使用する。この解決策は非常にシンプルで、入力と連結したい関数群を引数として渡すだけでよい。インターフェースはto.Bind3(input, fn1, fn2, fn3)のように、通常の関数呼び出しとほとんど変わらず、連結したい関数の数に対応する数字をタイプするだけなので、開発者の思考の流れを妨げにくい。このパッケージでは、1つから32個までの関数を連結するためのto.Bind1からto.Bind32までのバリエーションが提供されている。これにより、ほとんどのユースケースに対応できるだろう。

実際のコード例を見てみると、このパッケージの導入による効果は一目瞭然だ。

「Before」のコードSaveWithoutBind関数では、sanitize、correctCasing、getExtraInfo、submitという4つの処理が順に実行される。それぞれの処理の後に、必ずif err != nil { return "", err }というエラーチェックが記述されているため、ビジネスロジックとエラーハンドリングのコードが混在し、かなりの行数を占めていることがわかる。

一方、「After」のコードSaveWithBind関数では、同じ4つの処理がto.Bind4関数にまとめて渡されている。入力となるinputを最初の引数として渡し、その後ろに連結したい関数をカンマで区切って並べているだけだ。この記述により、各処理後のエラーチェックの行がすべてなくなり、関数全体がreturn to.Bind4(...)という非常に簡潔な形に収まっている。これにより、コードの行数が大幅に削減され、関数の主な目的である「保存処理」のロジックが非常に明確になった。エラーが発生した場合の早期リターンはto.Bind4が内部で自動的に処理してくれるため、開発者はその記述から解放される。

この「to」パッケージをGoプロジェクトに導入するのは非常に簡単で、go get github.com/ivypuckett/to@v1というコマンドを実行するだけでよい。

まとめると、「to」パッケージは、Go言語開発者が日常的に直面するエラーハンドリングのボイラープレート問題を解決するための強力なツールである。複数の処理を連続して実行し、途中で発生するエラーを効率的に処理することで、コードの可読性を大幅に向上させ、開発者の生産性を高めることに貢献するだろう。これにより、開発者はエラーチェックの記述に費やす時間を減らし、アプリケーションの本質的なロジックの実装に集中できるようになる。