問題タブ [exception]

私は.NET1.1アプリケーションを保守しており、私が担当していることの1つは、ユーザーに不適切なエラー通知が表示されないようにすることです。

Application.ThreadExceptionとにハンドラーを追加しましたAppDomain.CurrentDomain.UnhandledException。これらは呼び出されます。私の問題は、標準のCLRエラーダイアログがまだ表示されていることです（例外ハンドラーが呼び出される前）。

ジェフはこことここで彼のブログでこの問題について話します。しかし、解決策はありません。では、キャッチされない例外を処理し、わかりやすいダイアログボックスを表示するための.NET 1.1の標準的な方法は何ですか？

ジェフが提供したリンクには、必要なことを行う方法に関する最も完全な情報が含まれているため、ジェフの回答は正解としてマークされました。

Rails 1.2 Webサイトを2.1にアップグレードすると、ExceptionNotifierプラグインが機能しなくなり、次のエラーが発生します。

ActionView :: TemplateFinder :: InvalidViewPath：未処理のビューパスが見つかりました："/path/to/appname/vendor/plugins/exception_notification/lib/../views"。＃append_view_path、＃prepend_view_path、または＃view_paths=を使用してビューパスを設定します。

何が原因で、どうすれば修正できますか？

C++ の例外は、呼び出し元の関数でキャッチする必要はありません (コンパイル時のエラーはありません)。そのため、(Java とは異なり) try/catch を使用してそれらをキャッチするかどうかは、開発者の判断に任されています。

呼び出し元の関数が try/catch を使用して、スローされた例外が常にキャッチされるようにする方法はありますか?

例外処理の仕組みに完全に満足したことはありません。多くの例外があり、try / catchがテーブルにもたらします（スタックの巻き戻しなど）が、その過程で多くのOOモデルが壊れているようです。

とにかく、ここに問題があります：

ネットワーク化されたファイルIO操作をラップまたは含むクラスがあるとします（たとえば、どこかの特定のUNCパスにあるファイルの読み取りと書き込み）。さまざまな理由で、これらのIO操作を失敗させたくないので、失敗を検出した場合は再試行し、成功するかタイムアウトに達するまで再試行を続けます。私はすでに便利なRetryTimerクラスを持っており、これをインスタンス化して、再試行の間に現在のスレッドをスリープさせ、タイムアウト期間がいつ経過したかなどを判断するために使用できます。

問題は、このクラスのいくつかのメソッドに多数のIO操作があり、それぞれをtry-catch/retryロジックでラップする必要があることです。

コードスニペットの例を次に示します。

では、クラス全体のすべてのファイルIO操作でこのコードのほとんどが重複しないようにするにはどうすればよいでしょうか。私の解決策は、匿名のデリゲートブロックと、渡されたデリゲートブロックを実行するクラスの単一のメソッドを使用することでした。これにより、他の方法でこのようなことができるようになりました。

私はこれがやや好きですが、それはまだまだ望まれていません。他の人がこのような問題をどのように解決するのか聞きたいです。

プロパティの単純なセッター メソッドがありnull、この特定のプロパティには適していません。私はいつもこの状況で引き裂かれてきました: IllegalArgumentException、またはを投げるべきNullPointerExceptionですか? javadocs から、どちらも適切に見えます。ある種の理解された基準はありますか？それとも、これは好きなようにすべきことの 1 つにすぎず、どちらも本当に正しいのでしょうか?

したがって、Javaでは、コンストラクターの最初の行はsuperの呼び出しである必要があります...暗黙的にsuper（）を呼び出す場合でも、明示的に別のコンストラクターを呼び出す場合でも同じです。私が知りたいのは、なぜその周りにトライブロックを配置できないのですか？

私の特定のケースは、テスト用のモッククラスがある場合です。デフォルトのコンストラクターはありませんが、テストを読みやすくするためのコンストラクターが必要です。また、コンストラクターからスローされた例外をRuntimeExceptionにラップしたいと思います。

だから、私がやりたいのは事実上これです：

しかし、Javaは、superが最初のステートメントではないと不満を漏らしています。

私の回避策：

これは最善の回避策ですか？なぜJavaは私に前者をさせないのですか？

「なぜ」についての私の最も良い推測は、Javaが、潜在的に矛盾した状態の構築されたオブジェクトを私に持たせたくないということです...しかし、モックを行う際には、私はそれを気にしません。私は上記を行うことができるはずです...または少なくとも私は上記が私の場合には安全であることを知っています...またはとにかくそうあるべきであるように見えます。

テストされたクラスから使用するメソッドをオーバーライドしているので、初期化されていない変数を使用しているリスクはありません。

私は次のタイプのコードに何度も出くわしましたが、これが (パフォーマンスの観点から) 良い習慣であるかどうか疑問に思います:

基本的に、コーダーが行っていることは、例外をカスタム例外に含めて、それを再度スローすることです。

これは、次の 2 つとパフォーマンスがどのように異なりますか。

また

機能的またはコーディングのベスト プラクティスの議論はさておき、3 つのアプローチの間にパフォーマンスの違いはありますか?

しばらくの間、プレフィックス検索を行うアプリがありました。最近、インデックスのサイズが大きくなり、いくつかのプレフィックスがあまりにも多くて lucene が処理できないことが判明しました。Too Many Clausesエラーが表示され続け、JAR を確認し続け、含まれているコードのいずれも実際にブールクエリを使用していないことを確認したため、非常にイライラしました。

Too Many Hits 例外のようなものがスローされないのはなぜですか? そして、ブールクエリの静的な最大句の整数を増やすと、実際にこのエラーがなくなるのはなぜですか? 私が理解していないクエリの実行方法に基本的なものはありますか? それらがひそかにブールクエリになるということですか？

/clr でコンパイルされた MFC アプリケーションがあり、キャッチされないマネージ例外の最終ハンドラーを実装しようとしています。ネイティブ例外の場合、オーバーライドCWinApp::ProcessWndProcExceptionが機能します。

Jeff のCodeProject 記事で提案されている 2 つのイベントApplication.ThreadExceptionとAppDomain.CurrentDomain.UnhandledExceptionは発生しません。

混合実行可能ファイルに最終的なマネージド例外ハンドラーを提供する方法を提案できる人はいますか?

アップデート：

これらの例外ハンドラーは、ダウンストリームApplication.Runまたは同様のものでのみトリガーされるようです (ワーカー スレッド フレーバーがあり、名前を思い出せません)。マネージ例外を完全にグローバルにキャッチしたい場合は、SEH フィルターをインストールする必要があります。System.Exceptionコールスタックが必要な場合は、独自のウォーカーをロールバックする必要があります。

このトピックに関する MSDN フォーラムの質問では、try ... catch (Exception^). たとえば、CWinApp::Run. これは良い解決策かもしれませんが、パフォーマンスや安定性への影響については調べていません。保釈する前にコール スタックをログに記録する機会が得られ、デフォルトの Windows 未処理の例外動作を回避できます。

ユーザーコントロールを動的に読み込んで、WebフォームのControlsコレクションに追加しています。

レンダリング中に未処理の例外が発生した場合は、ユーザーコントロールを非表示にします。

そこで、各UserControlのErrorイベントにフックしてみましたが、Pageクラスの場合のように、このイベントがUserControlsに対して発生することはないようです。

いくつかグーグルをしましたが、それは有望ではないようです。ここに何かアイデアはありますか？