Visual Studio 2015が未処理の例外が機能しないためにブレークする
Visual Studioでは、「未処理の例外を解除する」という特定のチェックボックスが使用されていました。 2015年にこれは削除されました（または、見つからない場所に移動しました）。そのため、ユーザーレベルの例外ハンドラーを提供しなくても、変換されたプロジェクトが壊れなくなりました。特定の例外を処理するため、すべての「スローされた例外」を破りたくありません。特定のハンドラーを提供できない場合。
現在、私のコードは単に現在のプロシージャを終了し、次のコールスタックの場所で実行を継続します。
Visual Studio 2015でこれを取り戻す方法を知っている人はいますか？昨日、コミュニティエディションにアップグレードしました。
デバッグを開始すると、デフォルトで右下のペインに表示される「例外設定」という新しいウィンドウがあります。期待するすべてのオプションがあります。
あなたはそれを持ち出すことができます CTRL+ALT+E
これにより、デバッガーでブレークを引き起こす例外をチェリーピックできます。
ただし、重要なのは、これらの例外を常に中断するか、未処理の例外の場合にのみ中断するかを設定できることですが、これを設定することはあまり直感的ではありません。
最初に[ツール]> [オプション]> [デバッグ]で[マイコードのみを有効にする]をオンにする必要があります。
これにより、新しい[例外設定]ウィンドウで列ヘッダー（スローされるときに中断）を右クリックし、[追加アクション]列を追加できます。これにより、各例外を[ユーザーコードで未処理の場合に続行]として設定できます。
そのため、例外またはグループ全体を右クリックして、「ユーザーコードで未処理のまま続行」フラグを無効にします。残念ながら、「追加のアクション」列は空で表示されますが、これは「ユーザーコードで処理されない場合のブレーク」と同じです。
詳細はこちら：
私は同じ問題を抱えていて、これを行うことでこれを解決することができました-
- 押す Ctrl + Alt + e 例外設定ウィンドウを表示します。
- ティック共通言語ランタイムの例外。
![enter image description here]()
それでおしまい！
x64バージョンのWindowsを使用しているため、この post に触発されました。
例外がコードに関係する場合にのみ中断したいグーグルの場合、Visual Studio 2015にオプションがあります：[オプション]-> [デバッグ]-> [全般]-> [マイコードのみ]。一度チェックされると、コード外で例外が管理（スローおよびキャッチ）されたときに中断しないようにすることができます。
Microsoftは、新しい例外ウィンドウのロジックを微妙に変更しました。
重要な部分：
重要な注意事項
- この新しいウィンドウには、古いモーダルダイアログと同じ機能がすべて含まれています。デバッガの機能は、アクセス方法のみを変更していません
- デバッガーは、例外が処理されない場合は常に中断します
- ユーザーが未処理の例外でデバッガーが中断した場合に変更する設定は、コンテキストメニューの下に移動しました
- メニューの場所は、[デバッグ]-> [Windows]-> [例外設定]に移動しました
ただし、、私の場合は、コードにGlobal Unhandled Exception Handlerがあり、2番目の項目がそのリストが重要です。したがって、私にとって例外はまったく処理されません。VS2013とは異なるようです。
VSが未処理の例外で中断する動作を取り戻すために、中断したいすべての例外タイプにチェックマークを付け、次に「続行」の「追加オプション」（この列を表示する必要がある場合があります*） 「ユーザーコードで未処理の場合」がNOTに設定されていませんでした。 VS2015ロジックはありません私のグローバル未処理例外ハンドラーが「ユーザーコードで処理される」と見なされるようです」ので、これらを壊します。ただし、キャッチされた例外で中断することはありません。これにより、VS2013のように機能します。
*「追加アクション」列を有効にする方法 
ここで行間を正しく読んでいる場合、問題は、デフォルトのデバッガーの動作が未処理の例外で中断する場合でも、例外が事実上「消える」ことです。
非同期メソッドがある場合、タスクの継続の一部としてスレッドプールスレッドでキャッチされない例外は未処理の例外と見なされないため、この問題が発生する可能性があります。むしろ、それらは飲み込まれ、タスクとともに保存されます。
たとえば、次のコードを見てください。
class Program
{
static void Main(string[] args)
{
Test();
Console.ReadLine();
}
private async static Task Test()
{
await Task.Delay(100);
throw new Exception("Exception!");
}
}
このプログラムをデフォルトのデバッガー設定（未処理の例外でのみ停止）で実行すると、デバッガーは中断しません。これは、継続に割り当てられたスレッドプールスレッドが例外を飲み込み（タスクインスタンスに渡す）、プール自体に解放されるためです。
この場合、実際の問題は、Test()によって返されるTaskがチェックされないことに注意してください。コードに同様のタイプの 'fire-and-forget'ロジックがある場合、例外がスローされたときに表示されません（メソッド内で '未処理'であっても）。例外は、タスクを待機する、結果を確認する、または例外を明示的に確認することでタスクを監視する場合にのみ表示されます。
これは推測に過ぎませんが、このようなことを観察している可能性が高いと思います。
私の経験では、何かを変更すると、2015年の例外設定は完全に無効になります。
親グループ「CLR」までは、未処理の壊れたexecptを取得しないことを期待してください。例外が処理されない場合、常に中断します。ただし、CLRグループにチェックマークが付いていない場合、try ... catch内のコードは単にブレークを引き起こさないはずです。そうではありません。
解決策：新しい例外設定ツールボックスで、右クリックして「デフォルトの復元」を選択します。 Taadaaaa ...それは再び正常に動作します。今ではそれでねじ込まないでください。
指示に従ってください：
- [例外設定]ウィンドウで、ウィンドウを右クリックし、[列の表示]を選択してコンテキストメニューを開きます。 （Just My Codeをオフにしている場合、このコマンドは表示されません。）
- Additional Actionsという名前の2番目の列が表示されます。この列は、特定の例外でユーザーコードによって処理されない場合に[続行]を表示します。つまり、その例外がユーザーコードで処理されず、外部コードで処理される場合、デバッガーは中断しません。
- この設定は、特定の例外（例外を選択し、右クリックして、ユーザーコードで未処理の場合は続行を選択/選択解除）または例外のカテゴリ全体（たとえば、すべての共通言語ランタイム例外）に対して変更できます。
それはすべて少し混乱し、私の意見では、古い例外ダイアログほど良くはありませんが、とにかくです。
例外がリスト内にあり、チェックされている場合、デバッガーは例外がスローされるたびに中断します。
例外がチェックされていないか、リストにない場合、デバッガはその例外タイプがユーザーによって処理されていない場合にのみ中断します。
たとえば、次のスクリーンショットでは、System.AccessViolationExceptionがスローされるたびにデバッガーが中断しますが、他のすべての例外については、例外がユーザーによって処理されなかった場合にのみ中断します。
VS2015にアップグレードしたときに、アプリケーションを「破壊」するために例外が使用されていた問題もありましたが、現在は無視されてすぐに渡されます。コードを意図的に続けたいのではなく、停止したい場所で例外をスローしたい場合があります。コードを意図的に壊すために、常にThrow New Exception("Message")というフレーズを使用します。
If SomethingReallyBad = True Then
Throw New Exception("Something Really Bad happened and we cannot continue.")
End If
VS2015では、Throw New Exceptionと言うと、古典的な「System.Exception」がスローされます。したがって、新しい例外設定の「System.Exception」チェックをチェックする必要がありました。
チェックすると、コードは期待どおりに動作しました。
これに対する解決策は、あなたが設定していると思われるものと意味的に反対です。 ユーザーコードで処理されない場合に続行するが無効になっている、つまりチェックされていない例外設定タブのAdditional Actions列の下に表示-以下を参照：
あなたは事実上、コードで処理されていないときに続行しない（つまり中断する）と言っています
これをする：
- 右クリック関心のある例外または一連の例外（通常、ツリーの最上行の「共通言語ランタイム例外」）
- オプションを選択しますユーザーコードで未処理の場合に続行（以下を参照）
- 例外がチェックされていないことを確認してください（以下を参照）
- デバッグを続ける
それは私のためにそれをしました-再び幸せ。
これはVS 2015にありました
Visual Studioには、再起動が必要なスタック状態を引き起こす可能性のあるバグが間違いなくあります。 VS2015でも。
NullReferenceExceptionname__が（まだコード内で） 'outer'ハンドラによってキャッチされるシングルスレッドの状況がありました。
これは「処理された」例外であり、「処理されていない」例外であることを認識しています-ただし、IISRESETで解決できない場合は、VSをすばやく再起動すると修正されることがあります。
Visual Studio 2017はエラー処理で問題なく動作します。一方、Visual Studio 2015は、タスクでのエラー処理が面倒です。なぜなら、デバッグモードでは非同期タスクで発生するすべての例外がキャッチされますが、ステップオーバーすると、無限にハングするからです。デバッグせずに実行すると、例外をキャッチせずに無期限にハングします!!!私はビジュアルスタジオが大好きで、1995年からそれを使用しており、2010年から2015年に直接ジャンプしましたが、2015年と2015年ははるかに悪いバージョンです。この例外処理を成功させるために8時間費やしました。自宅のコンピューターで正確なコードを2017年にコピーしましたが、完全に機能しました。 Microsoftが2015コンパイラーが正しく処理できないフレームワークにタスクをプッシュしたことに非常にいらいらしています。