例外とソケットクライアントクラスの結果コード

Question

私はサーバーとのTCPソケット通信をカプセル化するクラスを持っています。サーバーに送信された各コマンド・メッセージについて、サーバーは常に応答コード（OK、Fail）を含む応答メッセージを戻します。私のクラスを使用すると、各コマンドはsyncまたはasyncのいずれかで実行できます。

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

これで、今すぐsyncコマンドメソッドは、OK、Fail、Faultの値を持つ列挙型を返します。例外が発生した場合、それは単純に（syncコマンドの）呼び出し側のスレッドに呼び出されます。非同期コマンドの場合、Resultプロパティのenum値にはOK、Fail、FaultまたはExceptionの余分な値を含めることができ、コールバックはコマンドオブジェクトのExceptionプロパティを介して実際の例外オブジェクトにアクセスできます。

この戦略についてどう思いますか？私は同期コマンドのために例外を発生させず、例外を内部的に記録し、代わりに4番目の列挙型の値を返すように誘惑されています。なぜなら、結果コードをすべて作成し、すべてのケースで例外を発生させます。

ありがとうございました。

Answer 1

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

例外の目的は例外的な条件に対処することです。問題の原因に近いほど、より良い。

あなたの戦略は、「今は動作しませんでした。再試行してください」というようなものです。私は実際に例外を発生させる理由は見ません。

クローズドソケットを扱うのがコード内で全く異なるフローを必要とするものだった場合は、例外が当てはまる可能性があります。あなたの説明から、それは事実ではありません。

例外の私の哲学は、あなたが本当に対処できない例外的な条件のためでなければならないということです。閉じたソケット？うーん...インターネットが何度も私の家に下ります...

Answer 2

結果コードと例外はどちらも正常に動作します。それは個人的な味方（そしてあなたのチームの他人の味）です。例外には、特に複雑な設定では、いくつかの利点がありますが、設定では、戻りコードが正常に機能するはずです。

人によっては口が泡立ち、例外を主張する人もいるかもしれませんが、私のプロジェクトの人々はリターンコードのシンプルさが好きなので、それらを全体的により良い選択にします。

Answer 3

これはむしろ興味深い質問です。したがって、おそらく100％正しい答えはなく、主に関数を使用するコードをどのように構造化する必要があると思われるかによって異なります。

私が見ているのは、あなたが関数を呼び出すコードに「悲惨な」状況から優雅に逃れる方法を提供したいときだけ、例外を使用することです。だから、私のコードでは、何か実際に何かが例外をスローすると、は本当にがひどく起き、呼び出し側が知る必要があります。

あなたが持っているものが正常で予想される状況であれば、おそらくエラー値を返すべきです。そうすれば、コードは「もっと頑張って」する必要があることを知っていますが、何が起こったかによって損なわれることはありません。

たとえば、タイムアウトを予期したものとして処理し、エラーコードを返したり、呼び出しコードがいくつかの追加アクションを実行する必要があるより深刻な問題（フル送信バッファなど）例外として 'normal'に戻ります。

しかし、美しさは視認者の目にあり、一部の人は例外や他の人（主にCプログラマ）のみがリターンコードを使用するように指示します。ただ覚えておいてください。は常にでなければなりません。 :)

Answer 4

私の好みでは、あなたのメソッドがミッションを成功裏に完了しなかった場合に例外をスローします。したがって、私が呼び出し元であるyourObject.UploadFile（）を呼び出すと、呼び出しが返ったときにファイルが正常にアップロードされたと見なされます。それが何らかの理由で失敗した場合、私はあなたのオブジェクトが例外をスローすることを期待します。再試行できるコマンドと再試行しないコマンドを区別したい場合は、その情報を例外に入れて、それに応じて対応する方法を決定することができます。

yourObject.BeginAsyncUploadFile（）を呼び出すと、ファイルのアップロードが成功したかどうかを調べるために、IAsyncResultまたは同等のオブジェクトを待つ必要がある点を除いて同じ動作が期待されます。例外/エラープロパティー。