3

エントリ ポイントからシステムのすべての例外を管理することが (ベスト プラクティスの意味で) 推奨されない理由。

class Program
    {
        static void Main(string[] args)
        {
              try
              {
                 [...]//all the program stuff
              }catch(Exception ex)
              {
                    [...]
              }
        }
    }

編集： 2番目のポイントで、パフォーマンスに何か変化はありますか?

4

2 に答える 2

5

実際に有用な方法で例外を処理できる場所で例外をキャッチする必要があるという意味では、お勧めできません。

例外についてクラッシュ以外に何もできない場合、ソリューションは機能しますが、たとえば、ファイルが見つからないために例外が発生することを考慮してください。「OpenFile」メソッド（または、この場合はファイルを開くメソッドの一部）のダイアログで処理し、続行する前にファイルの場所を参照する機会をユーザーに与えるか、またはむしろ、メインにスローバックして、「ログとクラッシュ」以外の実際のオプションはありませんか?

于 2012-10-05T08:23:19.073 に答える
1

このアプローチ：

  • 予想される例外を適切な場所、つまり発生したのと同じコンテキストで処理できる場所でキャッチすることを強調していません。
  • 別のスレッドで例外をキャッチしないため、マルチスレッド環境では機能しません。
  • .NET Framework によってインターセプトされるため、多くの Windows フォーム例外をキャッチしません。
  • プロセスが破損している場合を除き、すべての例外を飲み込みます。理解できない例外を飲み込んではいけないため、これは良いアプローチではありません。

より良いアプローチは、コンテキスト固有のメソッドで予期される例外をキャッチすることです。そこでは、例外を適切に処理するために利用できる知識が最も多くなります。予期しない例外をキャッチするために、Main メソッドは次のようになります。

// Event handler for handling all UI thread exceptions.
Application.ThreadException += 
    new ThreadExceptionEventHandler(App_UiThreadException);

// Force all Windows Forms errors to go through our handler.
// NB In .NET 4, this doesn't apply when the process state is corrupted.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

// Event handler for handling all non-UI thread exceptions. 
AppDomain.CurrentDomain.UnhandledException += new 
    UnhandledExceptionEventHandler(App_NonUiThreadException);

// Run the application.
于 2012-10-05T10:52:05.020 に答える