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 まで到達させる

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