MENU
  1. ホーム
  2. Ruby
  3. Railsでのエラーハンドリングとカスタムエラーページの設定方法を徹底解説

Railsでのエラーハンドリングとカスタムエラーページの設定方法を徹底解説

Ruby

Railsアプリケーションで運用中に発生するエラーや予期しない動作は、ユーザー体験に直接影響を与えます。特にエラーハンドリングとカスタムエラーページの設定は、ユーザーに対するアプリケーションの信頼性や使いやすさを左右する重要な要素です。デフォルトでは、Railsはエラー発生時に標準のエラーページを表示しますが、カスタムエラーページを設定することで、ユーザーが安心して利用できる工夫を施すことが可能です。本記事では、Railsにおけるエラーハンドリングの基本から、実際にカスタムエラーページを作成する手順まで、わかりやすく解説します。

目次
  1. Railsにおけるエラーハンドリングの基礎
    1. 主なエラーの種類
    2. Railsのエラー処理のデフォルト動作
  2. 標準的なエラーハンドリング手法
    1. rescueブロックによる例外処理
    2. rescue_fromメソッドによるエラーハンドリング
    3. エラーハンドリングにおける注意点
  3. カスタムエラーページの設定
    1. 1. カスタムエラーページのファイル作成
    2. 2. カスタムエラーページのデザイン
    3. 3. コントローラ経由でのエラーページ設定
    4. 4. ルーティング設定
  4. コントローラごとのエラーハンドリング
    1. 1. `rescue_from`メソッドの活用
    2. 2. エラーハンドリングの共有
    3. 3. 特定アクションのみのエラーハンドリング
  5. 例外クラスのカスタマイズ
    1. 1. カスタム例外クラスの作成
    2. 2. カスタム例外の発生とハンドリング
    3. 3. カスタム例外のハンドリング
  6. エラーハンドリングのベストプラクティス
    1. 1. エラーハンドリングを一元管理する
    2. 2. 明確でわかりやすいエラーメッセージ
    3. 3. 環境別のエラーハンドリング
    4. 4. ロギングとモニタリングの活用
    5. 5. ユーザーに役立つカスタムエラーページの提供
    6. 6. 定期的なエラーハンドリングの見直し
  7. 開発環境と本番環境でのエラーハンドリングの違い
    1. 1. 開発環境でのエラーハンドリング
    2. 2. 本番環境でのエラーハンドリング
    3. 3. 環境ごとのエラーハンドリング設定の推奨手法
  8. カスタムエラーページのデザイン例
    1. 1. 404 Not Foundページのデザイン例
    2. 2. 500 Internal Server Errorページのデザイン例
    3. 3. カスタムエラーページのデザインベストプラクティス
  9. エラーハンドリングとSEO
    1. 1. 正しいHTTPステータスコードの利用
    2. 2. カスタム404ページのコンテンツ最適化
    3. 3. サイトマップとロボットファイルの活用
    4. 4. モニタリングとエラーログの活用
    5. 5. リダイレクトの活用
    6. 6. エラーページに重要なキーワードを含める
  10. まとめ

Railsにおけるエラーハンドリングの基礎

Railsアプリケーションでのエラーハンドリングは、アプリケーションの安定性と信頼性を確保するために重要な役割を果たします。Railsでは、エラーが発生すると例外がスローされ、適切な処理が行われないとデフォルトのエラーページが表示されます。このセクションでは、Railsで一般的に発生するエラーの種類と、それぞれのエラーがどのように扱われるかを紹介します。

主なエラーの種類

Railsで発生する主なエラーには、以下のようなものがあります。

404 Not Foundエラー

リクエストされたページが存在しない場合に発生するエラーで、ユーザーが存在しないURLにアクセスしたときに表示されます。

500 Internal Serverエラー

サーバー内部で予期しないエラーが発生した場合に表示されるエラーで、コードのバグやサーバーの設定ミスが原因となることが多いです。

Railsのエラー処理のデフォルト動作

Railsでは、開発環境と本番環境でエラーハンドリングの動作が異なります。開発環境では詳細なエラー情報が表示され、デバッグを容易にしますが、本番環境ではエラーページがユーザーに表示されるように設定されています。

標準的なエラーハンドリング手法

Railsでは、標準的なエラーハンドリングとして例外処理機能を提供しており、rescueメソッドやrescue_fromメソッドを活用することでエラーに対する柔軟な対応が可能です。ここでは、Railsでよく使用されるエラーハンドリング手法を詳しく解説します。

rescueブロックによる例外処理

Railsでは、Rubyのbegin...rescue...endブロックを用いることで、特定の処理で発生したエラーを捕捉し、適切なエラーハンドリングを行えます。この方法を用いることで、特定のコードブロック内で発生したエラーだけを処理し、アプリケーションのクラッシュを防ぎます。

def create_user
  begin
    @user = User.create!(user_params)
  rescue ActiveRecord::RecordInvalid => e
    logger.error("User creation failed: #{e.message}")
    redirect_to error_page_path, alert: "ユーザー作成に失敗しました"
  end
end

rescue_fromメソッドによるエラーハンドリング

Railsのコントローラでは、rescue_fromメソッドを使用することで、特定の例外をグローバルにキャッチして処理できます。これにより、コントローラ全体でのエラーハンドリングを統一することが可能です。

class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordNotFound, with: :render_404
  rescue_from StandardError, with: :render_500

  private

  def render_404
    render file: "#{Rails.root}/public/404.html", status: :not_found
  end

  def render_500
    render file: "#{Rails.root}/public/500.html", status: :internal_server_error
  end
end

エラーハンドリングにおける注意点

エラーハンドリングでは、特定のエラーを適切にキャッチして処理しつつも、不要な例外が隠れないよう注意することが重要です。

カスタムエラーページの設定

Railsでは、デフォルトのエラーページ（404エラーや500エラー）をカスタマイズすることができます。これにより、ユーザーがエラーを経験した際にも、統一されたブランドイメージやデザインを維持しつつ、案内やメッセージを提供することが可能になります。このセクションでは、Railsでカスタムエラーページを設定する手順を解説します。

1. カスタムエラーページのファイル作成

まず、カスタムエラーページのHTMLファイルをpublicディレクトリに作成します。これにより、404や500のエラーが発生した場合に、Railsはこれらのファイルを表示するようになります。

public/404.html
public/500.html

2. カスタムエラーページのデザイン

作成したファイル内にHTMLやCSSを追加して、アプリケーションのスタイルに合わせたデザインを施します。また、ユーザーに役立つ情報やナビゲーションリンクを追加して、ユーザーが次に取るべきアクションを明確に示します。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>ページが見つかりません</title>
</head>
<body>
  <h1>404 Not Found</h1>
  <p>お探しのページは見つかりませんでした。</p>
  <a href="/">ホームに戻る</a>
</body>
</html>

3. コントローラ経由でのエラーページ設定

エラーページをより柔軟に制御したい場合は、カスタムコントローラを作成してエラーハンドリングに利用できます。ApplicationController内でrescue_fromを設定し、各エラーページを特定のアクションにリダイレクトします。

class ErrorsController < ApplicationController
  def not_found
    render file: "#{Rails.root}/public/404.html", status: :not_found
  end

  def internal_server_error
    render file: "#{Rails.root}/public/500.html", status: :internal_server_error
  end
end

4. ルーティング設定

次に、config/routes.rbにエラーページ用のルーティングを設定します。これにより、エラー発生時にカスタムコントローラのアクションが呼び出されるようになります。

Rails.application.routes.draw do
  # その他のルーティング
  match "/404", to: "errors#not_found", via: :all
  match "/500", to: "errors#internal_server_error", via: :all
end

これで、カスタムエラーページが設定され、Railsアプリケーションのエラーがよりユーザーフレンドリーに表示されるようになります。

コントローラごとのエラーハンドリング

Railsでは、アプリケーション全体でのエラーハンドリングに加えて、特定のコントローラごとに異なるエラーハンドリングを設定することも可能です。これにより、エラー内容やユーザーへの対応をコントローラごとにカスタマイズでき、複雑なアプリケーションでも柔軟にエラーハンドリングが行えます。このセクションでは、コントローラ単位でのエラーハンドリングの設定方法を説明します。

1. `rescue_from`メソッドの活用

特定のコントローラでのみエラーハンドリングを行いたい場合、コントローラクラス内でrescue_fromメソッドを使って例外をキャッチし、エラーハンドリングを行います。この方法は、例えば管理者用のコントローラとユーザー用のコントローラで異なるエラーメッセージやページを表示したい場合に便利です。

class AdminController < ApplicationController
  rescue_from ActiveRecord::RecordNotFound, with: :record_not_found

  private

  def record_not_found
    render file: "#{Rails.root}/public/admin_404.html", status: :not_found
  end
end

この例では、AdminController内でActiveRecord::RecordNotFoundが発生した場合に、管理者用の404ページ（admin_404.html）を表示します。通常の404ページとは異なるエラーハンドリングを行うことで、適切なエラー通知が可能になります。

2. エラーハンドリングの共有

複数のコントローラで共通のエラーハンドリングを行いたい場合、ApplicationControllerでエラーハンドリングを設定し、特定のコントローラに適用する方法もあります。この方法を用いると、コードの再利用性が向上し、メンテナンスが容易になります。

class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordNotFound, with: :render_404

  private

  def render_404
    render file: "#{Rails.root}/public/404.html", status: :not_found
  end
end

class ProductsController < ApplicationController
  # ProductsControllerはApplicationControllerの404エラーハンドリングを継承
end

このように、ApplicationControllerに定義したエラーハンドリングは、すべてのコントローラで使用されますが、個別のコントローラで上書きも可能です。

3. 特定アクションのみのエラーハンドリング

特定のアクションのみでエラーハンドリングを行いたい場合には、begin...rescue...endブロックを使用します。これにより、特定の処理に対して細かいエラーハンドリングが可能になります。

def show
  @product = Product.find(params[:id])
rescue ActiveRecord::RecordNotFound
  render file: "#{Rails.root}/public/404.html", status: :not_found
end

この例では、showアクション内でのみActiveRecord::RecordNotFoundが発生した際に404ページが表示されるように設定しています。

例外クラスのカスタマイズ

Railsでは、独自の例外クラスを作成することで、特定のエラー条件に対して個別のハンドリングを行うことが可能です。独自の例外クラスを導入することで、エラーの原因を明確にし、よりわかりやすいエラーメッセージや処理を提供できます。このセクションでは、Railsでのカスタム例外クラスの作成方法と、その活用方法について解説します。

1. カスタム例外クラスの作成

独自の例外クラスを作成するには、標準のStandardErrorクラスを継承して、特定のエラー用にクラスを定義します。例えば、特定の条件が満たされない場合にInvalidOperationErrorという例外を発生させたい場合、次のようにクラスを定義します。

class InvalidOperationError < StandardError
end

このInvalidOperationErrorは、通常のエラーと区別して処理するために使用できます。Railsのエラーハンドリングでこのカスタム例外を指定することで、エラーを特定の状況に合わせて処理できます。

2. カスタム例外の発生とハンドリング

カスタム例外を発生させたい場所でraiseメソッドを使って例外を投げ、コントローラやメソッド内で処理を行います。次の例では、特定の条件が満たされない場合にカスタム例外InvalidOperationErrorを発生させ、ユーザーにエラーメッセージを表示します。

def perform_operation
  if operation_invalid?
    raise InvalidOperationError, "この操作は許可されていません"
  end
  # 操作の実行コード
end

def operation_invalid?
  # 操作が無効かどうかの判定
end

カスタム例外が発生した際には、rescue_fromを使用してその例外に対応するエラーハンドリングを定義できます。

3. カスタム例外のハンドリング

作成したカスタム例外に対して、RailsのApplicationControllerでrescue_fromを使ってエラーハンドリングを設定します。これにより、アプリケーション全体での一貫したエラーハンドリングが実現できます。

class ApplicationController < ActionController::Base
  rescue_from InvalidOperationError, with: :handle_invalid_operation

  private

  def handle_invalid_operation(exception)
    render file: "#{Rails.root}/public/invalid_operation.html", status: :forbidden, alert: exception.message
  end
end

このようにして、InvalidOperationErrorが発生すると、指定したエラーページが表示され、ユーザーに操作が無効であることを明示できます。カスタム例外クラスは、エラーをより柔軟に扱うための便利な手段です。

エラーハンドリングのベストプラクティス

Railsでエラーハンドリングを効果的に行うためには、適切な設定やコードの書き方に加え、ユーザーと開発者の両方にとってわかりやすいエラーメッセージを提供することが重要です。以下では、Railsアプリケーションでエラーハンドリングを最適化するためのベストプラクティスを紹介します。

1. エラーハンドリングを一元管理する

エラーハンドリングの設定はApplicationControllerに集中させることで、メンテナンス性が向上します。rescue_fromメソッドを使ってアプリケーション全体のエラーハンドリングを統一し、特定のエラーに対して適切な処理を行います。

class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordNotFound, with: :render_404
  rescue_from StandardError, with: :render_500

  private

  def render_404
    render file: "#{Rails.root}/public/404.html", status: :not_found
  end

  def render_500
    render file: "#{Rails.root}/public/500.html", status: :internal_server_error
  end
end

2. 明確でわかりやすいエラーメッセージ

エラーメッセージは、ユーザーが何をすれば良いか理解できるように明確に伝えることが重要です。ユーザー向けのエラーメッセージはシンプルで、次のステップを提示する内容にしましょう。

3. 環境別のエラーハンドリング

開発環境と本番環境でエラーハンドリングを分け、開発環境では詳細なエラー情報を表示、本番環境ではカスタムエラーページのみを表示するよう設定します。この方法により、ユーザーに内部情報を公開せず、セキュリティリスクを軽減できます。

# config/environments/production.rb
config.consider_all_requests_local = false

4. ロギングとモニタリングの活用

エラーハンドリングには、エラーの記録（ロギング）とエラー発生の通知（モニタリング）も含めると効果的です。エラーが発生した際には、詳細な情報をログに記録し、例外監視サービス（例: SentryやRollbar）を利用して、リアルタイムでエラーの発生を把握します。

logger.error "Error message: #{exception.message}"

5. ユーザーに役立つカスタムエラーページの提供

ユーザーが迷わないように、カスタムエラーページにはホームページへのリンクや問い合わせ先などのナビゲーションを設けます。また、エラーを通知するボタンや再読み込みボタンなど、ユーザーが次に行うべき行動を示す要素を加えると効果的です。

6. 定期的なエラーハンドリングの見直し

アプリケーションが成長するにつれ、エラーハンドリングの要件も変化します。定期的にエラーハンドリングの設定やカスタムエラーページの内容を見直し、ユーザーに最適な体験を提供できるようにしましょう。

以上のベストプラクティスに従うことで、エラーハンドリングの品質を向上させ、ユーザーがエラーに遭遇しても適切に対応できるアプリケーションを構築できます。

開発環境と本番環境でのエラーハンドリングの違い

Railsアプリケーションでは、開発環境と本番環境で異なるエラーハンドリングの設定を行うことで、開発者の利便性とユーザーのセキュリティを両立させることができます。このセクションでは、環境ごとのエラーハンドリングの違いと、それぞれの環境での最適な設定方法について解説します。

1. 開発環境でのエラーハンドリング

開発環境（development）では、エラー発生時に詳細なエラーメッセージとバックトレース（エラーの発生箇所までの呼び出し履歴）が表示されます。これにより、開発者はエラーの原因を迅速に特定し、デバッグを効率的に行うことが可能です。

# config/environments/development.rb
Rails.application.configure do
  config.consider_all_requests_local = true  # エラー詳細表示を有効化
end

開発環境での利点

  • エラーメッセージの詳細表示：コードのどこでエラーが発生したかが即座にわかり、修正に役立ちます。
  • バックトレースの確認：どのメソッドやファイルで問題が発生したのか、正確に追跡できます。

2. 本番環境でのエラーハンドリング

本番環境（production）では、ユーザーに対して内部情報を隠すため、詳細なエラーメッセージは表示されません。代わりに、カスタムエラーページが表示されるように設定します。これは、アプリケーションのセキュリティを確保し、ユーザーにシンプルでわかりやすいエラーページを提供するためです。

# config/environments/production.rb
Rails.application.configure do
  config.consider_all_requests_local = false  # エラー詳細表示を無効化
end

本番環境での利点

  • セキュリティの向上：内部のエラーメッセージやコードがユーザーに露出せず、攻撃者に情報が漏れるリスクを低減します。
  • ユーザー体験の最適化：カスタムエラーページによって、ユーザーがエラーを目にしても混乱せずに行動を続けられるように案内できます。

3. 環境ごとのエラーハンドリング設定の推奨手法

  • モニタリングツールの導入：本番環境では、エラーが発生した際に開発者が即座に把握できるよう、SentryやRollbarといったエラーモニタリングツールの導入が推奨されます。
  • カスタムエラーページの設定：本番環境でユーザーフレンドリーなカスタムエラーページを用意し、エラー時もアプリケーションの一貫したデザインやブランドを保ちます。

このように、環境ごとに適切なエラーハンドリングを行うことで、開発者とユーザー双方にとって最適なアプリケーション動作が実現できます。

カスタムエラーページのデザイン例

カスタムエラーページは、エラーが発生した際にもユーザーが混乱せずに行動できるよう案内を提供する役割を持ちます。エラーページのデザイン次第で、ユーザーは不安を感じずに次のアクションを選べるため、エラーページもサイトのデザインやトーンに合わせてカスタマイズすることが推奨されます。このセクションでは、ユーザーフレンドリーなカスタムエラーページのデザイン例を紹介します。

1. 404 Not Foundページのデザイン例

404エラーページは、ユーザーが存在しないページにアクセスしたときに表示されます。このページでは、「ページが見つかりません」といったメッセージを表示し、ホームページや主要なページへのリンクを提供すると良いでしょう。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>ページが見つかりません</title>
  <style>
    body { text-align: center; font-family: Arial, sans-serif; }
    h1 { font-size: 48px; color: #333; }
    p { font-size: 18px; color: #666; }
    a { color: #007bff; text-decoration: none; }
  </style>
</head>
<body>
  <h1>404 - ページが見つかりません</h1>
  <p>お探しのページは存在しないか、削除された可能性があります。</p>
  <a href="/">ホームに戻る</a> | <a href="/contact">お問い合わせ</a>
</body>
</html>

ポイント

  • シンプルでわかりやすいメッセージ：「ページが見つかりません」と理由を明確に伝える。
  • ナビゲーションリンク：ホームページやサポートページなど、ユーザーが次にアクセスするためのリンクを提供。
  • 親しみやすいデザイン：サイトのデザインやトーンに合わせ、文字や配色に一貫性を持たせます。

2. 500 Internal Server Errorページのデザイン例

500エラーページは、サーバー内部でエラーが発生したときに表示されます。このページでは「内部エラーが発生しました」というメッセージを表示し、ユーザーがアプリケーションの問題だと理解できるようにします。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>内部エラーが発生しました</title>
  <style>
    body { text-align: center; font-family: Arial, sans-serif; background-color: #f8f9fa; }
    h1 { font-size: 48px; color: #e3342f; }
    p { font-size: 18px; color: #666; }
    a { color: #007bff; text-decoration: none; }
  </style>
</head>
<body>
  <h1>500 - サーバーエラー</h1>
  <p>申し訳ありません。内部エラーが発生しました。後ほど再度お試しください。</p>
  <a href="/">ホームに戻る</a>
</body>
</html>

ポイント

  • 謝罪のメッセージ：「申し訳ありません」など、エラーに対するお詫びの言葉を含める。
  • リトライの案内：「後ほど再度お試しください」と、ユーザーに対して次の行動を示唆。
  • カラーを使った視覚的な区分：エラーメッセージは赤や警告色を使い、背景は落ち着いた色を用いることで、視覚的にメインメッセージが引き立つようにする。

3. カスタムエラーページのデザインベストプラクティス

  • 一貫性のあるデザイン：アプリケーション全体のデザインと一致するスタイルにし、ブランドイメージを保つ。
  • 次の行動を促すリンク：ユーザーが迷わず次のページに進めるように、ホームやサポート、問い合わせページのリンクを提供。
  • 簡潔でフレンドリーなトーン：過度に専門的な用語を避け、ユーザーが理解しやすい言葉で案内を提供。

このように、エラーページもユーザー体験の一部としてデザインすることで、エラー発生時にも良好なユーザー体験を提供できます。

エラーハンドリングとSEO

エラーハンドリングはユーザー体験の向上だけでなく、SEO（検索エンジン最適化）にも重要な影響を及ぼします。エラーが頻発するサイトは検索エンジンからの評価が下がり、検索結果での順位が低下する可能性があります。このセクションでは、SEOを意識したエラーハンドリングのポイントと、エラーページの最適化方法について解説します。

1. 正しいHTTPステータスコードの利用

エラーハンドリングの際に、適切なHTTPステータスコードを設定することは、SEOにおいて不可欠です。404エラーや500エラーなど、エラーに応じた正しいステータスコードを返すことで、検索エンジンがページの状態を正確に認識できます。

  • 404 Not Found：存在しないページに対して使用し、検索エンジンにページが削除されたことを伝えます。
  • 500 Internal Server Error：サーバー内部の問題でアクセスできないページに対して使用し、一時的なエラーであることを示します。
# 404エラーの例
render file: "#{Rails.root}/public/404.html", status: :not_found

2. カスタム404ページのコンテンツ最適化

404エラーページは、ユーザーに役立つ情報を提供する機会でもあります。404ページには、関連コンテンツやナビゲーションリンクを配置することで、ユーザーがサイト内を継続して閲覧できるように誘導します。また、適切なメタ情報や説明文を追加することで、検索エンジンにとっても有益なページとなります。

3. サイトマップとロボットファイルの活用

検索エンジンにインデックスされるページを適切に制御するため、サイトマップとrobots.txtファイルを活用します。削除したページやアクセス制限がかかったページについては、これらのファイルでクローラーのインデックスを防ぐことで、エラーが検索エンジンに影響しないようにします。

4. モニタリングとエラーログの活用

検索エンジンの評価を守るためにも、エラー発生の頻度を把握し、適切に対応することが重要です。エラーログやモニタリングツールを使って頻繁に発生するエラーを監視し、ユーザーがエラーに直面する機会を最小限に抑えます。

5. リダイレクトの活用

削除したページやURLが変更されたページには、301リダイレクトを設定して新しいページに誘導します。301リダイレクトを設定することで、SEOの評価を引き継ぎつつ、ユーザーがエラーページに到達することを防ぎます。

# 301リダイレクトの設定例
redirect_to new_path, status: :moved_permanently

6. エラーページに重要なキーワードを含める

カスタムエラーページには、サイトやサービスに関連するキーワードを適度に含めることで、エラーページが検索エンジンの評価に悪影響を及ぼさないようにします。適切なメタタグやタイトルタグを設定し、ユーザーにとって役立つ内容にすることがポイントです。

これらの対策を通じて、エラーハンドリングの品質がSEOに悪影響を与えないようにし、サイト全体の検索エンジン評価を維持することが可能です。

まとめ

本記事では、Railsでのエラーハンドリングとカスタムエラーページの設定方法について詳しく解説しました。適切なエラーハンドリングは、アプリケーションの信頼性向上とユーザー体験の向上に直結します。Rails標準のエラーハンドリング機能に加え、カスタムエラーページや独自例外クラスを活用することで、より柔軟でユーザーフレンドリーな対応が可能です。また、SEOを意識したエラーハンドリングの最適化により、検索エンジン評価への悪影響を防ぐことも重要です。エラーハンドリングを適切に実装し、強固でユーザーに優しいアプリケーションを目指しましょう。

Ruby
エラーハンドリング カスタムエラーページ Ruby Rails

コメント

コメントする

目次
  1. Railsにおけるエラーハンドリングの基礎
    1. 主なエラーの種類
    2. Railsのエラー処理のデフォルト動作
  2. 標準的なエラーハンドリング手法
    1. rescueブロックによる例外処理
    2. rescue_fromメソッドによるエラーハンドリング
    3. エラーハンドリングにおける注意点
  3. カスタムエラーページの設定
    1. 1. カスタムエラーページのファイル作成
    2. 2. カスタムエラーページのデザイン
    3. 3. コントローラ経由でのエラーページ設定
    4. 4. ルーティング設定
  4. コントローラごとのエラーハンドリング
    1. 1. `rescue_from`メソッドの活用
    2. 2. エラーハンドリングの共有
    3. 3. 特定アクションのみのエラーハンドリング
  5. 例外クラスのカスタマイズ
    1. 1. カスタム例外クラスの作成
    2. 2. カスタム例外の発生とハンドリング
    3. 3. カスタム例外のハンドリング
  6. エラーハンドリングのベストプラクティス
    1. 1. エラーハンドリングを一元管理する
    2. 2. 明確でわかりやすいエラーメッセージ
    3. 3. 環境別のエラーハンドリング
    4. 4. ロギングとモニタリングの活用
    5. 5. ユーザーに役立つカスタムエラーページの提供
    6. 6. 定期的なエラーハンドリングの見直し
  7. 開発環境と本番環境でのエラーハンドリングの違い
    1. 1. 開発環境でのエラーハンドリング
    2. 2. 本番環境でのエラーハンドリング
    3. 3. 環境ごとのエラーハンドリング設定の推奨手法
  8. カスタムエラーページのデザイン例
    1. 1. 404 Not Foundページのデザイン例
    2. 2. 500 Internal Server Errorページのデザイン例
    3. 3. カスタムエラーページのデザインベストプラクティス
  9. エラーハンドリングとSEO
    1. 1. 正しいHTTPステータスコードの利用
    2. 2. カスタム404ページのコンテンツ最適化
    3. 3. サイトマップとロボットファイルの活用
    4. 4. モニタリングとエラーログの活用
    5. 5. リダイレクトの活用
    6. 6. エラーページに重要なキーワードを含める
  10. まとめ