Grape での例外処理のマスター:カスタム エラー、ベスト プラクティス、AppSignal の統合

Grape は、RESTful API を構築するための人気のある Ruby フレームワークです。例外処理は、Grape で作成されたアプリケーションを含むあらゆるアプリケーションの安定性と信頼性を確保する上で重要な役割を果たします。

この記事では、例外のカスタマイズなど、Grape 例外処理の基本について説明します。また、いくつかのベスト プラクティスと、アプリを AppSignal と統合してエラーの監視と管理を強化する方法についても触れます。

始めましょう!

Grape 例外処理の基本

このチュートリアルでは、Rails に組み込まれた Grape API で例外を処理する方法を見ていきます。このためにデモの求人掲示板 API を作成しました。GitHub でソース コードをチェックアウトできます。

例外の発生

Grape では、error! を使用して例外を発生させることができます。 。たとえば、上記のジョブ API には、show があります。 ID に基づいてジョブを返すルート 。 404 を返すことができます。 次のようなレコードが利用できない場合のエラー:

例外を発生させるときは、それを「独自の」方法で処理する必要があります。おそらく、発生した例外をユーザーに送信したくないでしょう。

Ruby には、例外処理のためのデフォルトのメカニズムがあります。例外を発生させる可能性のあるコードを begin でラップすることで機能します。 ブロック。 rescue ブロックは、発生した例外を処理するために使用されます。

一般的なシナリオでは次のようになります。

rescue_from メソッド

例外が発生した場合、または直接関与せずに例外が発生した場合は、それらを適切に処理する必要があります。デフォルトでは、Grape は rescue_from を提供します。 方法。これにより、定義された例外が発生したときに実行されるコードのブロックを指定できます。

したがって、404 を「救出」または処理するには jobs で発生する他のエラーよりも先に発生したエラー リソースでは、rescue_from を使用できます。 方法。メソッドは jobs の上に追加されます。 リソース。

使用するコンテンツ タイプを指定することもできます。

この例外処理方法は汎用的すぎます。あらゆる形式の例外をレスキューし、404 のエラーを返します。 ステータスコード。 API ユーザーが 400 を受け取ることを期待している場合、これは誤解を招きます。 ステータス コード。

代わりに、処理したい例外を指定できます。

ActiveRecord::RecordNotFound が発生した場合 エラーが発生した場合は、404 のエラー メッセージが返されます。 ステータスコード。それ以外の場合は、500 のエラー メッセージが返されます。 ステータス コード。

これは、現在あるものを改善できることを示していますが、 そのすべてから救うエラー ハンドラーが必要な場合はどうなるでしょうか。 エラー?そこで、例外のカスタマイズが役に立ちます。

Grape for Ruby での例外のカスタマイズ

発生したエラーの種類に応じて、このエラー ハンドラーは正しいステータス コードとともにエラー メッセージを返すことができる必要があります。

まず、Exceptions_handler というファイルを作成します。 。次に、現在の例外ハンドラーをファイルに移動します。

私たちの ExceptionHandler モジュールは ActiveSupport::Concern を使用します これにより、included などの機能にアクセスできるようになります。 および class_methods 。上のスニペットでは、included にエラー ハンドラーがあります。 ブロックなので、このモジュールが含まれる場所であれば、定義どおりに使用できます。

先に進んで、以前にエラー ハンドラーが存在していたファイルからエラー ハンドラーを削除できます。次に、ExceptionsHandler を含めることができます。 API エントリ ファイル内のモジュール — api.rb :

エラーの基本エラー クラスを作成しましょう。このクラスは、エラー応答を返す役割を果たします。

このクラスは 2 つのキーワード パラメータ、message を受け入れます。 文字列と status 。何も渡されない場合は、デフォルトが使用されます。

body 内 メソッドでは、Rack 応答を返します。デフォルトでは、rescue_from ハンドラーは Rack::Response を返す必要があります オブジェクト、error! を呼び出します 、または例外を発生させます。

ExceptionsHandler でそれを利用することができます。 :

/error を呼び出すと、 エンドポイント、oops が表示されます 応答として返されました。この時点で、NotFound のクラスを作成できます。 エラー。

NotFound クラスは message のみを受け入れます 。 BaseError を継承しているため 、Rack::Response を返す必要はありません。 ExceptionsHandler で使用できます。 このように:

ここで、次のようなエラーを手動で発生させようとすると、次のようになります。

これは正常に動作しますが、ステータス コードは 500 になります。 応答が BaseError で返されるためです。 クラス (BaseError として) クラスがエラーを処理します)。これを修正するには、ExceptionHandler を変更する必要があります。 NotFound を明示的に使用するには 代わりにエラーを処理するクラス。

したがって、ActiveRecord::RecordNotFound に対応するエラーが発生するたびに、 と V1::Exceptions::NotFound が発生した場合は、Exceptions::NotFound を使用してください 。それ以外の場合は、Exceptions::BaseError を使用します。 .

特定のrescue_from が必要であることがわかります。 さらにエラークラスを作成するときにブロックします。 case ステートメントを使用することでこれを改善できます。

さあ、出来上がり！

ベスト プラクティスとヒント

例外処理に採用できるベスト プラクティスは数多くありますが、従うべき簡単なヒントをいくつか紹介します。

<オル>

グループ関連の例外:上記のコードで見たように、関連する例外をグループ化すると、コードを保守しやすくなります。処理したい例外の数が増加した場合、それらをリストに追加できます。

error! などのヘルパーを使用する すぐに例外を発生させるため。これにより、例外処理が簡素化されます。

AppSignal などの例外監視ツールを活用する

AppSignal の統合:Ruby 用の Grape

AppSignal は、アプリケーションのエラーを監視および追跡するのに役立ちます。 AppSignal を Grape API と統合すると、例外に関する貴重な洞察が得られます。このガイドでは、AppSignal を Grape API と統合する方法を説明します。API でエラーが発生すると、次のように AppSignal ダッシュボードにエラーが表示されます。

まとめ

例外処理は、堅牢な API を開発する上で重要な側面です。このチュートリアルでは、Grape API で例外を適切に処理する方法を説明しました。また、いくつかのベスト プラクティスと AppSignal の Grape への統合についても簡単に説明しました。

例外処理は継続的なプロセスであり、継続的に改善する必要があります。

コーディングを楽しんでください!

追記Ruby Magic の投稿を報道後すぐに読みたい場合は、Ruby Magic ニュースレターを購読して、投稿を 1 つも見逃さないようにしてください。

追伸。 AppSignal が Active Record 統合を提供していることをご存知ですか?詳細をご覧ください。

キングスリー チジョケ