カスタム関数内の例外の処理

Question

私たちは皆try tryブロックを使用します。しかし、カスタム関数内のエラーを処理する最善の方法は何ですか？

例外がスローされたとき（関数内で可能な場合）にメッセージボックスを表示するか、関数内でエラーが検出されたことを示す値を返しますか？

Answer 1

本当に関数に依存しますが、一般的には、ユーザーにMessageBoxを表示させないようにアドバイスします。これはUIのタスクです。関数（有効な理由で）がにMessageBoxを表示する場合は、関数の呼び出し元がMessageBoxを防ぐことができるように、「サイレント」になることが保証されたオーバーロードを提供します。しかし、私が言ったように、呼び出し元に例外処理の方法を決定させる方が良いと思います。結局のところ、UIがないWindowsサービスから関数が呼び出された可能性があります。

私は通常、これらのアプローチのいずれかを使用します。

• は、すべての例外をキャッチではなく、上向きのバブルそれをさせません。これは、単に関数内にtry-catchブロックを実装しないことによって行われます。
• 例外をキャッチし、それをログに記録して何かをしてから、再度スローします。
• 例外をキャッチし、スローされた新しい例外（おそらくいくつかのロギングが完了している）でラップします（InnerExceptionとして）。

これは、関数自体が例外を処理できない場合に適用されます。場合によっては、関数が例外状態を処理してもその作業を実行できることがあります。これらのケースでは、もちろんその関数によって例外はスローされません。

Answer 2

私はすべてのエラーをトップレベルにバブルアップさせています。アプリケーションエラーハンドラを使ってそれらをすべて処理します。

私が知っている特定のエラーがある場合、その関数で発生する可能性があり、その関数はそれを処理することができます。

タイムアウト、オブジェクト参照が設定されていないなどトップハンドラに移動します。

Answer 3

あなたが何かできないという例外をキャッチしないでください。 try/catchブロックで散らばっているコードは読みにくく、メンテナンスを容易にするために、例外処理コードが1か所に含まれていないことを意味します。

例外をログに記録する場合や、ユーザに警告する場合は、スタックの最上部（またはアプリケーション層の境界）で行う必要があります。 Application.ThreadExceptionイベントとAppDomain.CurrentDomain.UnhandledExceptionイベントを使用し、Sub Mainメソッドのイベントハンドラに接続します。