1

私は例外を多用し始めました。長所と短所を難しい方法で学ぶことで成長すると確信していますが、例外の第一人者になるまでは、この手法が許容されます。

私は自分の 'SorryFailedToSaveYourData' 例外でデータベース例外をラップしてから、次のようにメッセージを表示する例外を再帰的に移動するつもりです:

Try
    DoSomeWork
Catch
    BuildErrorMessage(lblError,ex)
End Try

Public Sub BuildErrorMessage(ByVal lbl As Label, ByVal ex As Exception)
    lbl.Text += "<br />" & ex.Message
    While Not ex.InnerException Is Nothing
        BuildErrorMessage(lbl, ex.InnerException)
    End While
End Sub

このプラクティスは役に立ちますか、それとも例外の処理に関して完全に理解できていないのでしょうか? 独自の例外を作成できることは承知していますが、私たちが取り組んでいるプロジェクトの規模を考えると、やり過ぎのように思えます。

ありがとう

4

4 に答える 4

2

ex.ToString() はフォーマットされた例外テキストを作成します。デバッグに必要な完全な情報が得られない可能性があるため、.Message ではなくそれを使用する必要があります。

また、AppendLine() を使用してラベルの代わりに stringbuilder を再帰的に渡すことをお勧めします。この方法では、そのテキストを使用してメール通知を送信したり、イベント ビューアーやログ ファイルを作成したりすることもできます。UI に表示するには (html が必要なようです)、ラベルのテキスト値を次のように設定します。

StringBuilder.ToString().Replace(Environment.NewLine, "<br />")
于 2009-01-20T22:31:24.633 に答える
2

アプリケーションのユーザーにすべての内部例外メッセージを表示するわけではありません。私は実際の例外 (つまり SqlException) をキャッチし、それを独自の例外として再スローします (つまり、 new YouCantSaveThisTwiceException("This customer ID already exists") をスローします)。次に、その手で入力したメッセージを、見栄えの良いディスプレイ画面でユーザーに表示するだけです。完全なスタック トレースを含む電子メール/ログ ファイルなどを自分自身に送信します。

これには次の 2 つの目的があります。

1) 実際のスタック トレースを確認できるため、問題の特定と修正が容易になります。

2) ユーザーに大きな恐ろしいスタック トレースを表示する必要はありません。代わりに、彼らはあなたが書いた素敵なメッセージを読んで、問題はあるもののアプリケーションを「壊した」わけではないことを安心させます。

これは、ユーザーが別の入力で修正できるとは思わない例外に対してうまく機能します。ユーザー入力を検証する例外については、多くの場合、プレゼンテーション層でそれらをキャッチし、フォームを離れることなくラベルに素敵なメッセージを表示できます。

何をキャッチしようとしているのかを正確に知っていて、それを修正する方法についてユーザーに明確な指示を与える場合にのみ（のみ!!!）、この手法を使用してください。そうしないと、両方の世界で最悪の事態に陥ります。ユーザーは何をすべきかわからず、バグの存在についても警告を受けません。単に「すべての例外をキャッチ」するためにメソッド全体を try-catch でラップしないでください。この種の処理は、アプリケーション レベルでグローバルに行う必要があります。

Global.asax 内の application_error ハンドラー メソッドで、すべてのグローバル例外処理 (メール送信、ログ記録など) を行います。アプリケーション エラーを処理する HttpModule を作成することもできます。その後、その機能をプロジェクト間で持ち運ぶことができます。

于 2009-01-21T04:42:42.247 に答える
0

おそらく、ユーザーにメッセージを表示したいため、例外内にラベルを作成しています。例外がアプリケーションの複数の層にまたがる場合 (独自のデータ例外をラップすることについて言及しました)、カプセル化に違反し、例外処理で UI 要素を使用するように強制されるため、これはひどい考えです。

ただし、通常は、ユーザーにエラー メッセージを表示したくないでしょう。スタック オーバーフローが発生したことについて、ユーザーは何を気にしますか? 彼は、アプリケーションが壊れていることと、エラー レポートがログに記録され、適切なチームに送信されたことだけを気にしています。

一般に、アプリケーションがもはや実行できない状態にある場合にのみ、例外を設定する必要があります。条件付きで発生するだけの場合は、例外メカニズムを使用するのではなく、条件を指定して明示的に処理し、チェックする必要があります。

たとえば、ユーザーが自宅から接続することがわかっていて、インターネット接続があることを保証できない場合は、単にインターネットを使用しようとするのではなく、インターネット接続を確認し、ユーザーが接続する必要があることを示すメッセージを表示します。存在しない場合は例外を作成します。

于 2009-01-20T14:25:57.577 に答える
0

編集

私は最初にあなたの質問を読み違えました。エンド ユーザーに情報を表示する場合、おそらくこれを実行したくないでしょう。後でトラブルシューティングするために例外をログに記録する場合は、私が提案していることを実行する必要があります。

====

これは標準ですが、スタック トレースと Data プロパティの項目もキャプチャします (ただし、これを使用するフレームワーク コードは見たことがありませんが、独自の例外をスローしたり、例外を再スローしたりする場合に役立ちます。

実際のコードにはエラーがありますが、外側の例外には常に内側の例外があるため、おそらく無限ループに陥ります。

Public Sub BuildErrorMessage(ByVal lbl As Label, ByVal ex As Exception)   
 lbl.Text += "<br />" & ex.Message    
 If Not ex.InnerException Is Nothing     Then
    BuildErrorMessage(lbl, ex.InnerException)    
  End If 
End Sub
于 2009-01-20T14:27:16.077 に答える