2

C# を使用して Thrift サービスを試しています。REST サービスでは、キャッチされなかった例外が Web フレームワークによって HTTP 500 応答コードに変換されます。

私が知る限り、倹約では、可能なすべての例外の種類を倹約ファイルで宣言する必要があります。それにより、私が考えることができる2つのオプションが残ります。

  1. InternalServerError 型を宣言し、すべてのメソッドに追加します。すべてのハンドラー メソッドは、未処理の例外をキャッチし、特殊な型を再スローする必要があります。
  2. この場合、クライアントにデフォルトの動作を体験させます。これは、ソケットが予期せず閉じているようです。

最初のオプションは機能しますが、かなり一般的なケースのように思われる場合、かなりの回避策になるようです。内部で使用されている TApplicationException があることに気付きました。

サーバー側で捕捉されなかった例外を倹約ユーザーが処理する慣用的な方法は何ですか?

4

1 に答える 1

2

HTTP 500

REST サービスでは、キャッチされなかった例外が Web フレームワークによって HTTP 500 応答コードに変換されます。

これは、「キャッチされていない例外でサーバー呼び出しが惨めに失敗するようにする」の婉曲表現です。REST フレームワークはこれらのポリシーに従います。REST は HTTP 動詞、応答、および動作を中心に意図的に設計されているためです。つまり、逆です。HTTP ステータス コードは、REST 実装に何らかの形で追加されるのではなく、REST の基本原則です。

慣用的な例外処理

サーバー側で捕捉されなかった例外を倹約ユーザーが処理する慣用的な方法は何ですか?

短い答え：あなたはそれを望んでいません。

キャッチされなかった例外は、運が良ければ一般的な TApplication 例外に変換されますが、既に説明したように、予期せずに閉じられたトランスポートなどの影響をキャッチすることもあります。明らかに、欠点は、クライアントに転送する可能性のあるすべての情報、コンテキスト、および例外の詳細が失われることです。したがって、少なくとも 1 種類の例外を用意し、それをonewayメソッド以外のすべてのサービス呼び出しに追加することをお勧めします。

なぜoneway方法ではないのですか？

厳密に言えば、追加することもできます。Thrift コンパイラはそれを無視します (新しいバージョンでは警告が発行されます)。実際、onewayメソッドは値を返すことはなく、例外も返さないため、このthrows節は ではまったく役に立ちませんoneway。

例外ハンドラのオーバーヘッドが大きすぎませんか?

別の方法は、上記で説明した望ましくない動作を受け入れることです。しかし、それはThriftが設計された方法ではなく、長期的には利益よりも多くの苦痛を生み出すでしょう.

かなり一般的なケースのように見えるものに対して、かなりの回避策があるようです。

あまり。コーディングに関しては、最小限の追加作業しかありません。それは事実です。しかし、その努力に対して得られるものにも目を向ける必要があります。

一般的に言えば、API ファサード (Thrift に限定されない) で例外ハンドラーを持つことは、とにかく良いことです。これらの例外ハンドラーは最後の砦として機能し、多くの場合、ログ記録、セキュリティ関連のインターナのサニタイズなどの追加の目的を果たします。パフォーマンスに関しては、例外が発生するとコストがかかります。例外ハンドラーが純粋に存在することによるパフォーマンスへの影響は非常に限られています。

TApplicationException を再利用したり、そこから派生したりできますか?

内部で使用されている TApplicationException があることに気付きました。

TApplicationExceptionは内部使用のみを目的としており、TTransportExceptionおよびについても同様ですTProtocolException。また、それらから派生させるべきではありません。IDL ファイルで例外を宣言するだけで、残りは Thrift コンパイラーに任せることができます。

于 2014-01-13T21:23:03.810 に答える