問題: コントローラで例外処理している
アプリケーションが扱うドメイン特有のエラーを例外として表現する場合に、その例外をコントローラで処理するコードを書くと、ほとんどの場合でコードが読みにくくなったり、コードを変更しづらくなったりする結果となる。そして、開発の効率が落ちたり不具合を作りやすくなったりする。
具体的な問題は次のとおり。
コントローラのアクションの凝集度が下がる
コントローラのアクションに、たとえば複数の決済方法のエラーのような微妙に異なる種類の例外に対する処理を書くと、コントローラが肥大化し、凝集度が下がる。結果として、エラーが関わる変更を入れるときに、本来ビジネスロジックだけの変更であっても、コントローラとモデルの両方を必ず変更しなければならなくなる。また、関係の薄いさまざまな例外が1箇所で処理されることになり、コードが読みにくくなる。
class ChargesController < ApplicationController
def create
rescue FooPay::Error
rescue BarPay::Error
rescue BazPay::Error
end
end
さらに、こういうコードは「ここで例外処理しているから今回のも追加しておくか」という心理を誘発しやすい（割れ窓）。持続的なWebアプリケーション開発は割れ窓との戦いである。
テストの負担が増える
コントローラ層を対象としてテストする場合、いちいち結合テスト（近年のRailsだとintegration testまたはrequest spec）を書く必要がある。プレーンなクラスやいわゆるモデルなどと比較するとテストの準備が大変になるし、テストの実行速度も落ちる。また、異常系はとくにだが、しばしばリクエストやコンテキストを含めた複雑な事前状態を作る必要があり、読みにくいテストになる。
テストがしづらいところにがんばってテストを書くことはできるが、それは問題解決になっていない。
原因
そもそもコントローラはHTTPのことをやるところだが、それ以上の責務を負わせているのが上述した問題の主な原因といえる。
コントローラは、外から来るリクエストを受け取って、レスポンスを作って返すというのが本来の責務。HTTPに基づいてパラメータやヘッダのパース、Cookieの管理、レスポンスの生成などを実行する。
つまり、コントローラはレイヤードアーキテクチャのUI層やプレゼンテーション層にあたる。これらの責務やレイヤーには、アプリケーションの中核となるビジネスロジック（アプリケーションが解決する問題領域に固有のロジック）は含まれない。
一方、ビジネスロジックはモデルで扱う。これはレイヤードアーキテクチャで言うとドメイン層やモデル層と呼ばれるところ。ビジネスロジックを実行中に処理を継続できなくなったら発生させたいエラーは本来ビジネスロジックとして処理するべきだが、このエラーがモデルを外から利用しているコントローラにまで侵食してくると、上述したような問題が発生する。
解決策
本当に例外を使うべきか考える
ビジネスロジックにおけるエラーは「例外」ではないはず、とまず考えたい。たとえば、ユーザーが変な値を送信してきたときにそれを不正としてエラーを返すのは、例外的ではなく想定内のはず。別の側面だと、例外は制御構造から大域脱出するので、多用するとコードを読むときの負荷を高めうる。
例外の定義の1つを引いてくると『オブジェクト指向入門 第2版 設計・コンセプト』の12章に「例外とはルーチンコールの失敗を引き起こす可能性のある実行時イベントである」とある。つまり、例外とは、ルーチン（メソッド）の実行時に最後まで期待どおり実行できない可能性がある事態の発生を表す*1。
どのようなエラーを例外として表現すべきか。技術的な例外としては外部サービスとの通信の失敗や、NoMethodErrorなどの実行時エラーがある。また、ビジネスロジックの例外としては、データとビジネスルールのあいだの不整合などで一度開始したトランザクションを続けられない状態になったとき発生させる例外が考えられる。これらのケースを除くと、本当に例外が必要ではないケースもそれなりにある。
そこで、エラーをできるだけ例外ではない方法で表現できないかを考える。たとえば、ビジネスロジック実行前のデータの検証失敗時に例外を起こすのではなく、検証の実行結果を取得できるような設計にする。これは、RailsだとActiveModel::Validationをうまく使い、入力値に関するエラーは戻り値、またモデルやフォームオブジェクトの属性として取得する事になる。
モデル層で適切にビジネスロジックを書く
ビジネスロジックに関するエラーをコントローラで処理するようになることが問題の原因だと書いた。ビジネスロジックに関するエラー処理をモデル層でやるためには、RailsのActive Recordのモデル（つまり、アクティブレコードパターンに基づいたDBのテーブルに対応しているクラス）だけではなく、必要に応じてふつうのクラスを作るようにする。そして、そのなかでエラー処理をやる。Railsならプレーンなクラスでもいいし、コントローラやビューで使えるようにするならActive Model (ActiveModel::Model)を使ってもよい。
このようなクラスをうまく作るためには、リソースだけではなくアプリケーションにおけるイベントもモデルとして抽出したり、ユースケースを見出してクラスにする必要がある。この話題については、非常にわかりやすくまとまっている次の文献を参照されたい。
トランザクションを張る場合は、例外を発生させることでトランザクションをロールバックする形になる。このケースにも対応するための案としては、次のようにビジネスロジックの一部としてロールバックと例外処理を実行し、このモデルを使う側からは実行結果だけが取得できるよう方法がある。これができると、コントローラは薄くなり、scaffoldしたときの構造に近くなる。
class Foo < ApplicationRecord
def execute_some_business_logic
transaction do
foobar!
save!
end
true
rescue ActiveRecord::RecordInvalid
false
rescue Foo::SomeError
false
end
end
class FoosController < ApplicationController
def update
@foo = Foo.find(params[:id])
if @foo.execute_some_business_logic
else
end
end
end
DBと通信できないなどの技術的な例外はそもそもプログラムの実行を続けられないはずなので、ここで処理せず呼び出し元まで例外を突き抜けさせるのがよい。
FAQ: 404、500などのエラーにしたいときはコントローラより上の層で例外処理する必要があるのでは？
利用しているフレームワークにもよるが、404や500などの一般的、技術的エラーはアプリケーション共通の処理を定義していることが多いので、そういうケースで例外を発生させるのは問題なさそうに思う。たとえば、PUT /foos/:foo_id/bars/:bar_idのようにパスパラメータとしてIDが入るリソース設計にすると、
fooとbarは最初にコントローラでDBから探す- それらのレコードが見つかったら、そこからビジネスロジックに処理を依頼する
という流れになる。このときは、fooかbarがなければ、コントローラで例外処理をすることになる。
class BarsController < ApplicationController
rescue_from ActiveRecord::RecordNotFound do
end
def update
foo = Foo.find(params[:foo_id])
@bar = foo.bars.find(params[:bar_id])
if @bar.update(bar_params)
end
end
end
