4

Ruby で特定のコード ライブラリを使用する場合、どの例外をレスキューすればよいか分からないことがよくあります。

たとえば、私の rails/sinatra アプリが作成する HTTP リクエストには、HTTParty をよく使用します。HTTParty のコードを調べたところ、使用されている定義済みの例外を含むファイルが見つかりました。すごい！依頼の際に救出するだけです。

テストするために、リクエストに偽のドメイン名を入力しましたが、予期した HTTParty::ResponseError 例外ではなく、SocketError 例外が発生しました。

これに対処する最善の方法は何ですか？HTTParty が Ruby の実装のラッパーであることは承知しており、それがおそらく SocketError 例外をスローした原因です。しかし、どうすれば通常それを知ることができますか?

「例外」をレスキューするだけでこれを解決できましたが、それはかなりひどい習慣です。私はむしろ、私が引き起こしている可能性のある例外を十分に認識し、それらに対処したいと考えています.

編集:この質問を作成するように本当に促したのは、特定の関数を呼び出すときに発生する可能性のある例外をどのように把握できるかわからないことであることを明確にする必要があります...つまり、すべての関数呼び出しを調べずにスタックで。

4

3 に答える 3

6

大まかに言うと (私は Ruby プログラマーではありません)、次のアプローチを使用します。

私は例外を次のように扱います。

  • 回復できますか？ 例外が発生する可能性があり、おそらく回復または再試行できることがわかっている場合は、例外を処理します。

  • 報告する必要がありますか？ 例外が発生する可能性があるが、おそらく回復または再試行できないことがわかっている場合は、例外をログに記録して呼び出し元に渡すことで例外を処理します。私は常に、主要なモジュールやサービスなどの自然なサブシステムの境界でこれを行います。場合によっては (API によって異なります)、呼び出し元が私の例外のみを処理できるように、「私のモジュール」固有の例外で例外をラップすることがあります。

  • それを処理できませんか？処理されないすべての例外は最上位で捕捉され、(a) 報告され、(b) システムの安定性と一貫性が保たれるようにする必要があります。これは、他の 2 つが完了しているかどうかに関係なく、常に存在する必要があるものです。

もちろん、別のクラスの例外があります。非常に深刻なため、対処する機会がありません。これらの解決策は 1 つだけです - Post Mortem のデバッグ。そして、小規模から大規模まで多くのシステムに取り組んできたので、安定性と回復可能性のためにパフォーマンスを犠牲にし（重要な場合を除く）、大量のログを追加することを好みます-可能であれば内省的に。

于 2012-07-25T01:46:04.907 に答える
0

偽のドメイン名を入力しても、socketError 応答は問題ありません。結局、存在しないドメインに接続しようとすると、接続が失敗し、別名 SocketError が発生します。

これに対処する最善の方法は、テストで偽の URL を持つ有効なドメインを使用することですが、実際のコードで socketError をキャッチします。

ここでの問題は、間違った例外をキャッチしていることではなく、悪いデータでテストを準備していることです。

最善の行動は、どのような例外が発生する可能性があるかを理解し、それらを管理することです。私が理解していると言うとき、私は次のようになります - URL はどこから来たのか、ユーザーによって入力されたのか? もしそうなら、それを決して信用せず、すべてを捕まえてください。それはあなたの設定データから来ていますか？URL が正常であることがミッション クリティカルでない限り、半信半疑でエラーをログに記録します。

ここに正しい答えも間違った答えもありませんが、このアプローチが良い結果をもたらすことを願っています。

編集: ここで私がしようとしているのは、自分の行動の結果を認識しているプログラマーの考え方を支持することです。「thisServiceIsTotallyBogus.somethingbad.notAvalidDomain」に接続しようとすると失敗することは誰もが知っています。しかし、プログラマーの考え方は、最初にそのドメインがどこから来たのかを正確に検証することです。ユーザーが入力した場合は、完全なチェックを想定する必要があります。自分自身またはサポート チームのみがアクセスする構成ファイルからのものであることがわかっている場合。少しリラックスできます。残念ながら、インターネットが機能しない場合があるため、常に URL をテストする必要があるため、これは悪い例です。

理想的には、使用するすべての開発者向けドキュメントで、どのような例外がスローされる可能性があるかを説明する必要があります。

于 2012-07-25T01:43:58.920 に答える