2

サーバーとのtcpソケット通信をカプセル化するクラスがあります。サーバーに送信されるコマンドメッセージごとに、サーバーは常に応答コード(OK、失敗)を含む応答メッセージを送り返します。私のクラスを使用すると、各コマンドはsyncまたはasyncのいずれかで実行できます。

発生する可能性のある例外には、基本的に2つのタイプがあります。切断またはその他の回復不能なエラーによって引き起こされる「障害」と、「バッファがいっぱいです」などの予期しない例外です。障害が発生した場合、接続が再確立されるまで、コマンドを続行したり、再試行したりすることはできません。応答が失敗した場合、または例外が発生した場合でも、コマンドを再試行できます...

したがって、現在、私のsyncコマンドメソッドは、OK、Fail、Faultの値を持つことができる列挙型を返します。例外が発生した場合は、(syncコマンドで)呼び出し元のスレッドに発生します。非同期コマンドの場合、Resultプロパティの列挙値に追加の値(OK、Fail、Fault、またはException)を含めることができ、コールバックはコマンドオブジェクトのExceptionプロパティを介して実際の例外オブジェクトにアクセスできます。

この戦略についてどう思いますか?同期コマンドに対して例外をまったく発生させず、内部で例外をログに記録し、代わりに4番目の列挙値を返すようにしたいと思います。とにかくどのような場合でも例外を実際に処理するのはそれだけだからです...または、使用しないでください結果コードはすべて、障害も含めてすべての場合に例外を発生させますか?

ありがとう。

4

4 に答える 4

1

あなたの戦略は基本的に健全だと思います。

例外の目的は、例外的な状況に対処することであることに注意してください。問題の原因に近ければ近いほどよい。

あなたの場合、あなたの戦略は「今はうまくいきませんでした。もう一度やり直しましょう」のようなものです。本当に例外を発生させる理由がわかりません。

閉じたソケットの処理が、コード内でまったく異なるフローを必要とするものである場合、おそらく例外が理にかなっているでしょう。あなたの説明からすると、実際にはそうではありません。

例外に関する私の哲学は、実際には対処できない例外的な状況のためのものであるべきだということです。閉じたソケット?うーん...私の家では何回インターネットがダウンしますか...

于 2008-09-26T19:05:38.807 に答える
1

私の好みは、メソッドがその使命を正常に完了しないときはいつでも例外をスローすることです。したがって、呼び出し元である私が yourObject.UploadFile() を呼び出すと、呼び出しが返されたときにファイルが正常にアップロードされたと見なされます。何らかの理由で失敗した場合、オブジェクトが例外をスローすることを期待しています。再試行できるコマンドと再試行すべきではないコマンドを区別したい場合は、その情報を例外に入れれば、それに応じてどのように反応するかを決めることができます。

yourObject.BeginAsyncUploadFile() を呼び出すとき、ファイルのアップロードが成功したかどうかを確認するために IAsyncResult または同等のオブジェクトを待機する必要があることを除いて、同じ動作を期待します。しませんでした。

于 2008-09-26T19:21:33.200 に答える
0

結果コードと例外はどちらも正常に機能します。それは個人の好み (およびチームの他のメンバーの好み) の問題です。例外には、特により複雑な設定ではいくつかの利点がありますが、あなたの設定では、戻りコードが正常に機能するほど単純に思えます。

口に泡を吹いて例外を主張する人もいますが、私のプロジェクトではリターンコードのシンプルさが好きで、全体的にはリターンコードの方が良い選択です。

于 2008-09-26T19:02:14.227 に答える
0

これはかなり興味深い質問です。そのため、おそらく「100% 正しい」答えはありません。ほとんどの場合、関数を使用するコードをどのように構成する必要があるかによって異なります。

私が見た方法では、関数を呼び出すコードに「悲惨な」状況から優雅に脱出する方法を提供したい場合にのみ、例外を使用します。したがって、私のコードでは、何か本当に恐ろしいことが起こり、呼び出し元が知る必要がある場合、通常は例外をスローします。

今、あなたが持っているのが通常の予期された状況であれば、おそらくエラー値を返すはずです。そうすれば、コードは「もっと頑張る」必要があることを認識しますが、起こったことによって妥協することはありません。

あなたの場合、たとえば、タイムアウトを期待どおりに扱うことができるため、エラーコードを返し、呼び出し元のコードが「通常」に戻るために追加のアクションを実行する必要がある、より深刻な問題 (完全な送信バッファーなど) を返すことができます。 '例外として。

しかし、美しさは見る人の目にあり、例外のみを使用するように言う人もいれば、戻りコードのみを使用するように言う人もいます (ほとんどの場合 C プログラマー)。覚えておいてください、例外は常に例外的であるべきです。:)

于 2008-09-26T19:05:46.200 に答える