Ruby の例外処理をマスターする:実践ガイド

AppSignal では、Ruby アプリケーションのエラー追跡を提供しています。そのために、アプリケーションがスローするすべての例外をキャプチャし、例外が発生したときに開発者に通知します。

例外処理を正しく行うのは難しい場合があります。この記事では、その仕組み、不適切な処理によってどのような問題が発生する可能性があるか、例外を適切にレスキューする方法について説明します。

例外のレスキュー

Ruby で例外をレスキューすることで、何か問題が発生した瞬間にアプリケーションがクラッシュするのを防ぐことができます。 begin .. rescue の場合 ブロックを使用すると、エラーが発生したときにアプリケーションの代替パスを指定できます。

どの例外を救済するかを指定することもできます。例外クラスを指定すると、この例外のすべてのサブクラスもキャプチャされます。

上の例では、例外 Errno::ENOENT が発生していることがわかります。 親 SystemCallError のときにキャッチされます 救出中です。

例外チェーンの上位にあるレスキュー

例外チェーンの上流にある例外をレスキューしないことが重要です。これを行うと、サブクラス化された例外もすべてキャッチされるため、レスキュー ブロックのキャプチャが汎用的になりすぎます。

これは、プログラムに渡された引数に基づいて設定ファイルを読み取るプログラムです。

エラー メッセージには、設定ファイルを読み取れなかったことが示されていますが、実際の問題はコードのタイプミスでした。

begin .. rescue によってキャッチされたデフォルトの例外クラス ブロックは StandardError です。特定のクラスを渡さない場合、Ruby は StandardError とすべてのサブクラス化されたエラーをレスキューします。 NoMethodError はこれらのエラーの 1 つです。

特定の例外クラスをレスキューすると、無関係なエラーが誤って障害状態を引き起こすことを防ぐことができます。また、エンドユーザーにとってより役立つ、より具体的なカスタム エラー メッセージも可能になります。

例外のレスキュー

例外チェーンの上位でレスキューすることは依然として魅力的かもしれません。アプリケーションが発生させる可能性のあるすべてのエラーを解決すると、アプリケーションのクラッシュを防ぐことができます。 (稼働率 100% が実現しました!) ただし、多くの問題が発生する可能性があります。

Exception クラスは、Ruby の主要な例外クラスです。他のすべての例外はこのクラスのサブクラスです。例外がレスキューされると、すべてのエラーが捕捉されます。

ほとんどのアプリケーションが救済したくない 2 つの例外は、SignalException と SystemExit です。

SignalException は、外部ソースがアプリケーションに停止を指示する場合に使用されます。これは、シャットダウンする場合はオペレーティング システム、またはアプリケーションを停止する場合はシステム管理者である可能性があります。例

SystemExit は exit の場合に使用されます。 Ruby アプリケーションから呼び出されています。これが発生すると、開発者はアプリケーションを停止することを望みます。例

例外をレスキューし、アプリケーションが現在 begin ... rescue ... end を実行しているときにこれらの例外が発生した場合 ブロックすると終了できません。

通常の状況で Exception をレスキューすることは一般に悪い考えです。 Exception をレスキューすると、SignalException と SystemExit だけでなく、LoadError、SyntaxError、NoMemoryError なども機能しなくなります。代わりに、より具体的な例外を救済する方が良いでしょう。

テストの失敗

rescue Exception => e を使用して例外を救済する場合 、アプリケーションの隣にある他のものが壊れる可能性があります。テスト スイートは実際にはいくつかのエラーを隠している可能性があります。

minitest および RSpec では、アサーションが失敗すると例外が発生し、アサーションが失敗したことを通知し、テストが失敗します。その場合、Exception からサブクラス化された独自のカスタム例外が発生します。

テストまたはアプリケーション コードで例外がレスキューされた場合、アサーションの失敗が沈黙している可能性があります。

例外が予想されます

一部のコードは例外を発生させることを目的としています。テスト スイートでは、例外が発生したときにテストが失敗しないように、単純に例外を黙らせることができます。

ただし、例外が発生したかどうかはテストされません。例外が発生しない場合、テストでは動作が依然として正しいかどうかを判断できません。

例外が発生したかどうか、発生しなかった場合はどの例外が発生したかをアサートすることができます。

例外を再発生させる

アプリケーションは、非常に正当な理由がある場合にのみ、チェーンの上位にある Exception クラスの例外をキャプチャする必要があります。たとえば、実際に削除する必要がある一時ファイルを削除するなど、コード ブロックを終了する前に何らかのクリーンアップが必要な場合です。

例外をどうしてもレスキューする必要がある場合の推奨事項の 1 つは、エラーの処理が完了した後に例外を再発生させることです。このようにして、Ruby の例外処理がその後のプロセスの運命を決定することができます。

何を救出すればよいかわかりませんか?

前述したように、どのエラーを救済するかを具体的に指定することをお勧めします。

操作でどのような例外が発生するかわからない場合は、StandardError のレスキューから始めるとよいでしょう。さまざまなシナリオでコードを実行し、どのような例外が発生するかを確認してください。

新しい例外に遭遇するたびに、それらの例外またはその関連する親クラスに対する特定のレスキュー ケースを追加します。あまりにも多くの例外を救済するよりも、何を救済するかを具体的にする方が良いでしょう。

これで、Ruby における例外処理の入門は終わりです。さらに詳しく知りたい場合、または具体的な質問がある場合は、@AppSignal までお知らせください。アプリ内で例外が発生する場所と頻度についてさらに詳しく知りたい場合は、AppSignal を試してみてください。

トム・デ・ブルーイン