3

この質問に対する明確な答えがあることを願っています。

アイテム ID などの追加のプロパティを使用してカスタム例外を拡張し、受信側クライアントが例外を分析できるようにすることが望ましいですか?

別の方法は、すべての重要な情報をメッセージ文字列に隠すことです。または、実際の結果と追加のコンテキスト情報を含む複雑な戻り値で例外を置き換えます。これは、そうでなければ例外のプロパティにありました。

アドバイスありがとうございます！

4

1 に答える 1

0

それは本当にシナリオに依存します。通常、それが実際の例外 (実行中のメソッドを停止するもの) である場合、例外クラスを拡張する最初のオプションを使用します。

シナリオが何であれ、文字列オプションは悪いように聞こえます。

複雑な戻りオブジェクトは、発生する可能性のあるさまざまな問題のレイヤーがある応答 (たとえば、HttpResponse) のようなものについて話すとき (通信がないためにスローされる例外ですか? 認証エラーですか? または実際の論理例外ですか?サーバー側？）

于 2013-04-15T13:44:26.190 に答える