はじめに

bettr_errorsはRubyのgemで、特にRails開発において有用なツールだそうです。
コマンドを覚える必要もなく、開発環境においては入れるだけ得！なgemです。

使い方

特徴

詳細なエラーページを表示してくれる
エラーが発生した場所でコードを試行できる
エラーが発生した時点の変数を確認できる
エラーが発生したソースコード周辺を表示してくれる

以上の特徴により、問題の原因を突き止めやすくなります。

インストール

1. `Gemfile`に追記

group :development, :test do
  # ...省略

  gem 'better_errors'
  gem 'binding_of_caller'

  # ...省略
end

binding_of_callerは、エラーが発生したコードの呼び出し元も教えてくれるgemです。
better_errorsと一緒に使用されることが多い。

2. 追記したgemのインストール

$ docker compose run web bundle install

3. （リモートアクセスの場合）どのIPからのアクセスを許可するか書く

Dockerを使用している場合も同様
config/environments/development.rbファイルに追記

Rails.application.configure do
  BetterErrors::Middleware.allow_ip! "0.0.0.0/0"

  # ...省略
end

4. サーバーの再起動

Dockerの場合はdocker compose upを一度終了し、再度docker compose upを行う。

コマンド・メソッド

better_errorsはエラーページを拡張するgemであり、新しいコマンドやメソッドを追加することはありません。

雑記 `raise` メソッドで`better_errors`の挙動を確認する

raiseメソッドによりエラーを発生させることで、better_errorsがどのようなエラーページを表示するのかを簡単に確認することができます。

終わりに

以下の疑問と回答で締めさせていただきます。

Q. better_errorsは標準搭載されていても良いように思いますが、なぜ標準搭載されないのでしょうか？

開発環境でのみ有用で、サービス提供においては不要だからでしょうか？

A. `better_errors` がRubyやRailsの標準搭載されていない理由にはいくつかの考慮点があります。

その中でも特に重要なのは、開発環境と本番環境でのニーズの違い、セキュリティの懸念、および柔軟性の維持です。

開発環境と本番環境のニーズの違い:

better_errors は開発環境でのデバッグを効率化するために設計されています。開発者はエラーの原因を迅速に特定し、修正するために詳細な情報を必要とします。

一方、本番環境では、セキュリティやパフォーマンスの観点から、エラー情報の詳細な表示は避けるべきです。本番環境のエラーハンドリングは、ユーザーに対する適切なフィードバックとログ記録に焦点を当てるべきです。

セキュリティの懸念:

better_errors はエラーに関する詳細な情報を提供するため、不正なアクセスによる情報漏洩のリスクがあります。本番環境ではこのような詳細情報を外部に露出させることは好ましくありません。

柔軟性の維持:

RubyやRailsは柔軟性とカスタマイズ可能性を重視しています。全ての開発者やプロジェクトが同じツールやライブラリを必要とするわけではないため、標準搭載することは必ずしも最適ではありません。

プロジェクトの要件やチームの好みに応じて、異なるデバッグツールやエラーハンドリングのアプローチを選択できるべきです。

パフォーマンスと依存関係の管理:

標準搭載すると、そのツールの依存関係やパフォーマンスへの影響をすべてのユーザーが負うことになります。特に大規模なフレームワークでは、余分な依存関係を最小限に抑えることが重要です。

結論として、better_errors は開発者が必要に応じて簡単に追加できるオプションとして提供されており、これによりRubyやRailsは幅広いニーズに柔軟に対応することができます。このようなアプローチは、開発環境のカスタマイズ性とセキュリティ、パフォーマンスのバランスを取る上で理想的です。

参考