背景
Railsのエラーページってデフォルトで静的ファイルで用意されていますよね。
public/404.html
public/500.html
ただ、実際に商用Webアプリを作っていると
- 「共通ヘッダ・フッタ」も表示したい！
- 他の動的部分で使っているcssとか画像を読み込ませたいけど静的ファイルだからassets_pathのパス解決ができない！
などのニーズが出て来ることも多いと思います。
そこで
http://morizyun.github.io/blog/custom-error-404-500-page/
のように rescue_from を使ってRailsアプリ側でエラーハンドリングしたり
rambulance を使って
404や500を動的表示できるようにカスタマイズしている人も多くいるようです。
考察
なぜRailsはエラー画面を静的ファイルで用意しているのか理由を自分なりに考えてみた。
1. 動的にViewを表示しようとするとそこにたどり着くまでに別のエラーが起こるリスクがある
例えばRailsのルートで404と判定→404のViewを表示するまでの間にエラーが発生した場合、それは404ではないエラーとユーザーに表示させてしまうことになります。
2. 404, 500はRailsの外でも使うケースがあり、静的ファイルの方が流用しやすい
商用環境になると、Railsをスタンドアロンで動かすことはないでしょう。
自分が携わっているRailsプロダクトではAWS環境上で運用することが多く
- CDN(Cloudfront)
- ロードバランサ（ELB）
- EC2（Nginx+Puma+Rails）
- ファイルストレージ（S3)
の構成にしています。
このケースを例にとると
Cloudfront, ELB, S3の部分にも404, 500エラーページ（それ以外のステータスも）を設定してあげる必要があります。そこで使えるのはもちろん静的ファイルなので、Railsで使っている404.html, 500.htmlがそのまま使えるとそれを配置するだけなので楽です。
3. そもそも動的に入り組んだことをさせるほどユーザーに見せてはいけないページ
基本的には
- 404エラー → リンク切れ
- 500エラー → 原因不明の障害
実装上の理由で上記が発生しているのであれば、それは実装で早急に解決すべきことです。
ユーザー操作の範囲で起こるものであれば、まとめて共通の500エラーを表示するのではなく、別途個別のControllerレイヤーでハンドリングしてエラーの旨を表示するのが筋です。
結論
上記の理由により静的ファイルに落ち着いているのだと推測しました。
完璧なDRYではないのかもしれないですが、特に考察2の用途を考えると静的ファイルで持ち回ったほうが生産的です。
以上、Railsの404, 505に関しては極力カスタマイズはせずRails wayに従って静的ファイルのままいきたいと思う今日このごろでした。