1

プログラムが開かれたとき（サーバーにサインインしたとき）に確立されたソケットを介して多くのデータを送信する、複数のユーザーコントロール、ウィンドウなどを備えた成長中のアプリケーションがあります。サーバーが停止したり、それらの線に沿って何かが発生した場合は、その特定の例外の try-catch ステートメントでほぼすべてのコード ブロックをラップするよりも、その後の SocketException をより適切な方法で処理できるようにしたいと考えています。

void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)

それを使用すると、スローされた未処理の例外をキャッチする必要があります。例外が socketexception であるかどうかを単純に確認してから、「切断されました。再接続してください」コードを起動するのは悪い考えですか? このアプリケーションでは、スローされた socketexception の 99% がサーバーの切断によるものであると安全に想定できます。

私がこの件について話している間、すでにキャッチされた後に例外の種類を確認する方法はありますか? 上記のコードでは、e.Exception を使用するだけで元の例外を取得できます。例外の種類をチェックするために if ステートメントをどのように表現すればよいかよくわかりません。

4

3 に答える 3

4

私見これは非常に悪い考えです...

より良い解決策は、ソケットにアクセスするコードを独自のクラスに移動することです...サーバーと対話する必要があるアプリケーション内のすべてがそのクラスを通過します...このようにして、ソケット関連の例外を中央で処理できます位置。

于 2012-04-06T14:04:07.930 に答える
1 
Using that should catch any unhandled exception that gets thrown

できることがほとんどない例外をすべてキャッチするのは得策ではありません。

Eric Lippert は、どの例外が処理されるかについて非常に優れた記事を書いています。

Socket にアクセスするコードが独自のクラスに移動したという Yahia の意見に同意します。

public class SocketHandling
{

 //if Something goes wrong, throw exception. It is up to the caller how to handle the exception.
}

main()
{
  try
{

}

catch(SocketRelatedException)
{
  //handle the exception.
}
}
于 2012-04-06T14:37:06.443 に答える
0

例外の種類をチェックするのは悪い習慣だとは思いません。

catch(Exception ex) 
            {
            if (ex is System.Net.Sockets.SocketException)
                {
                    doSomething(ex);
                }
            else 
              throw;

            }

また、特定の例外タイプをキャッチすることもできます...

于 2012-04-06T14:06:01.487 に答える