kakudooo docs

Active Recordとエラー処理

Railsにおける業務ロジックの中核を担のはActive Recordを中心としたモデル層なため、業務上のエラーを扱う機会も多くなる。Active Recordのエラーの扱いについて整理した上で、Active Recordを用いたアプリケーション実装時の方針について書いておきたい。

エラーについて

まず、エラーの分類を確認しておく。

業務エラーとシステムエラーに分類される

詳しくはエラー処理と設計を参照

Active Recordとエラー

Active Recordの役割

Active Recordとは、MVCで言うところのM、つまりモデルに相当するものであり、ビジネスデータとビジネスロジックを表すシステムの階層です。Active Recordは、データベースに恒久的に保存される必要のあるビジネスオブジェクトの作成と利用を円滑に行なえるようにします。Active Recordは、ORM（オブジェクト/リレーショナルマッピング）システムに記述されている「Active Recordパターン」を実装したものであり、このパターンと同じ名前が付けられています。

Railsガイドより

Active Recordの基となっている設計パターンである、Active Recordパターンは、永続化データとその振る舞いであるデータアクセスロジックをオブジェクトに含めておくことで、オブジェクトの利用者がDBの読み書きについて理解しやすくするためのものであり、主な機能として以下のようなものが挙げられる。

SQLの結果群の行からアクティブレコードのインスタンスを構築する
後でテーブルの挿入を行うために、新しいインスタンスを構築する
静的なfindメソッドを使用して、共通のSQLクエリをラップして、アクティブレコードオブジェクトを返す
データベースを更新して、更新したデータベースにアクティブレコードのデータを挿入する
フィールドを取得し、設定する
ビジネスロジックの一部を実装する

Patterns of Enterprise Application Architectureより

加えて、Active RecordにはORMフレームワークとして、RDBをリッチなオブジェクトとして表現するための、以下のような機能も実装されている

Association
Validation
Callbacks
参考
- https://speakerdeck.com/yasaichi/what-is-ruby-on-rails-and-how-to-deal-with-it?slide=40

エラーの発生しうる箇所

改めて簡単にまとめると、ORMフレームワークとしてのActive Recordの機能は以下

データベースやそのデータの関連をオブジェクト指向スタイルで操作可能にすること
データベースへの永続化前にバリデーションを行うこと

である。

発生しうるエラーの分類としては、以下である。

システムエラー
- DB接続時のエラーなど
業務エラー
- バリデーションやオブジェクトの操作、永続化時のエラーなど
参考
- https://speakerdeck.com/yasaichi/what-is-ruby-on-rails-and-how-to-deal-with-it?slide=50

Active Recordにおけるエラー表現

業務エラーのエラーオブジェクト作成、例外の通知について、基本的な部分については定義によるところもあるが、Active Recordがほとんどの部分の面倒を見てくれている。また、エラーを呼び出し元に通知する手段として、例外にするか、エラーオブジェクトにするかに関して利用者側から選択することができるようになっている。

例えば、参照、更新系のメソッドには破壊的メソッドを選択することが可能。

update
update!

Active Recordにおけるエラーハンドリングについての方針

!系メソッドの使用を最小限に抑える

例外によるエラーの通知は強力な機能ではあるものの、多用することで以下のような弊害もある。

rescueでハンドリングが必要となるため、凝集度や可読性の低下を招いてしまう
わざわざ例外→例外の流れを作ることで、本当に例外として通知すべきエラーへの意識が薄れてしまう

また、エラーのハンドリングはActive Recordもある程度やってくれるので積極的に活用したい。

呼び出し側はエラーオブジェクトでエラーを扱う

Active Recordの呼び出し側では、rescueによる例外のハンドリングを避ける。なるべくエラーオブジェクトを返り値として、明示的にエラーオブジェクトに応じて条件を分岐させる。

参考
- https://speakerdeck.com/yasaichi/what-is-ruby-on-rails-and-how-to-deal-with-it?slide=30

!系メソッドを使ってもいい時

業務エラーの中でも想定外の挙動が少しでも考えられる場合は!メソッドを使うことで、そのままTop Levelエラーとしてランタイムやフレームワークにエラーハンドリングを委ねる方が都合がよかったりするため。(システムエラーに近い扱いをする)

例えば

突き合わせ時にデータが想定外の状態になる可能性がある場合
エラーオブジェクトよりもRuntime errorになってほしかったり、500エラーとしてクライアントにレスポンスを返したい場合
など

使う場合は例外のハンドリングをModel層で行い、呼び出し側にはエラーオブジェクトを返すようにする。

参考
- https://blog.kymmt.com/entry/exception-handling-in-model

validationを定義する

createやsaveなど事前にバリデーションが実行されるメソッドのために定義しておく(Active Recordのエラーハンドリング機能をなるべく活用する)
valid?やinvalid?は場合に応じて使う
参考
- https://railsguides.jp/active_record_validations.html#valid-questionmark%E3%81%A8invalid-questionmark
- https://edgeguides.rubyonrails.org/association_basics.html

システムエラーとして扱うものは基本的にrescueしないで、例外をTop Levelまで到達させる

想定できていないエラーはランタイムやフレームワークに任せてしまう。エラー処理と設計を参照。