未処理の例外でVisual Studio 2015が機能しない

Visual Studioには、「未処理の例外でブレークする」という特定のチェックボックスがありました。2015年にこれは削除されました（または私が見つけられない場所に移動しました）。したがって、ユーザーレベルの例外ハンドラーを提供できない場合でも、変換されたプロジェクトが壊れることはなくなりました。私は特定の例外を処理するため、すべての「スローされた例外」を中断したくありません。特定のハンドラを提供できなかったところです。

現在、私のコードは単に現在のプロシージャを終了し、次の呼び出しスタックの場所で実行を続行します。GOODではありません。

誰もがこれをVisual Studio 2015に戻す方法を知っていますか？昨日、コミュニティエディションにアップグレードしました。

デバッグを開始すると、デフォルトで右下のペインに表示される「例外設定」という新しいウィンドウがあります。それはあなたが期待するだろうすべてのオプションを持っています。

CTRL+でそれを育てることができますALT +E

これにより、デバッガーで中断を引き起こす例外をチェリーピックできます。

ただし、重要な点は、これらの例外が常に中断するか、それが未処理の例外である場合にのみ中断するかを設定できることですが、これを設定することはあまり直感的ではありません。

まず、[ツール]> [オプション]> [デバッグ]の[コードを有効にする]をオンにする必要があります。

これにより、新しい[例外の設定]ウィンドウで列ヘッダー（[スロー時にスローする]）を右クリックし、[追加のアクション]列を追加して、各例外を[ユーザーコードで処理されない場合は続行する]として設定できます。

したがって、例外またはグループ全体を右クリックして、[ユーザーコードで処理されない場合に続行する]フラグを無効にします。残念ながら、[追加のアクション]列は空に表示されます。これは、[ユーザーコードで処理されないときに中断する]と同じです。

詳細はこちら：

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

私は同じ問題を抱えていて、これを行うことでこれを解決することができました-

1. Ctrl+ Alt+ eを押して、[例外設定]ウィンドウを表示します。
2. ティック共通言語ランタイム例外。

それでおしまい！

x64バージョンのWindowsを使用しているので、この投稿に触発されました。

例外がコードに関係する場合にのみ中断したいグーグルの場合、Visual Studio 2015にオプションがあります：オプション->デバッグ->全般->マイコードのみ。チェックすると、例外がコードの外部で管理（スローおよびキャッチ）されたときにブレークしないようにします。

マイクロソフトは、新しい例外ウィンドウのロジックを微妙に変更しました。

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspxを参照してください

重要な部分は次のとおりです。

重要な注意事項

• この新しいウィンドウには、古いモーダルダイアログと同じ機能がすべて含まれています。デバッガーの機能では、アクセスできる方法のみが変更されました
• 例外が処理されない場合、デバッガーは常に中断します
• ユーザーが処理しない例外でデバッガーが中断した場合に変更する設定は、コンテキストメニューの下に移動しました
• メニューの場所は、デバッグ->ウィンドウ->例外設定に移動しました

ただし、私のようにコードにグローバルな未処理の例外ハンドラーがある場合、そのリストの2番目の項目が重要です。したがって、私にとっては、VS2013とは異なり、例外が本当に処理されないことはありません。

VSが未処理の例外でブレークする動作を元に戻すには、ブレークしたいすべての例外タイプにチェックを入れ、次に「続行」の「追加オプション」（この列を表示する必要がある場合がある*）を確認する必要がありました。ユーザーコードで未処理の場合」が設定されていませんでした。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!");
    }
}

このプログラムをデフォルトのデバッガー設定（未処理の例外でのみ停止）で実行すると、デバッガーは中断しません。これは、継続に割り当てられたスレッドプールスレッドが例外を飲み込み（それをタスクインスタンスに渡します）、自身を解放してプールに戻すためです。

この場合、実際の問題は、によってTask返されたものTest()がチェックされないことに注意してください。コードに同様のタイプの「ファイアアンドフォーゲット」ロジックがある場合、例外がスローされたときに例外は表示されません（例外がメソッド内で「未処理」であっても）。例外は、タスクを待機するか、結果を確認するか、例外を明示的に確認することによってタスクを監視する場合にのみ表示されます。

これは推測にすぎませんが、このようなことを観察している可能性があります。

私の経験では、何かを変更した場合、2015年の例外設定はまったく問題なくスローされます。

親グループ "CLR"までは、ハンドルされていないために壊れたexecptを取得してはならないことを期待してください。例外が処理されない場合は常に中断します。ただし、CLRグループがチェックされていない場合は、try ... catch内のコードが中断を引き起こしてはなりません。そうではありません。

解決策：新しい例外設定ツールボックスで、右クリックして[デフォルトに戻す]を選択します。Taadaaaa ...再び正常に動作します。今それを台無しにしないでください。

指示に従ってください：

1. [例外設定]ウィンドウで、ウィンドウを右クリックして[列の表示]を選択し、コンテキストメニューを開きます。（Just My Codeをオフにしている場合、このコマンドは表示されません。）
2. 追加アクションという2番目の列が表示されます。この列には、特定の例外でユーザーコードによって処理されない場合は[続行]が表示されます。つまり、その例外がユーザーコードでは処理されず、外部コードで処理されても、デバッガーは中断しません。
3. この設定は、特定の例外（例外を選択して右クリックし、[ユーザーコードで処理されない場合は続行]を選択/選択解除する）または例外のカテゴリ全体（たとえば、すべての共通言語ランタイム例外）に対して変更できます。

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

それはすべて少し混乱します、そして私の意見では古い例外ダイアログほど良くありませんが、とにかく。

例外がリストにあり、チェックマークが付いている場合、デバッガーは例外がスローされるたびに中断します。

例外がチェックされていないか、リストにない場合、デバッガは、その例外タイプがユーザーによって処理されていない場合にのみブレークします。

たとえば、以下のスクリーンショットでは、デバッガーは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では、クラシックな "System.Exception"は、私たちが言うときにスローされるものですThrow New Exception。したがって、新しい例外設定で「System.Exception」の目盛りを確認する必要がありました。

System.Exceptionボックスをチェックする

チェックすると、コードは期待どおりに動作しました。

これに対する解決策は、意味的には、設定していると思っているものとは逆です。あなたはそれを確認する必要があります[ 例外設定 ]タブの[ 追加のアクション ]列に表示されるように、ユーザーコードで処理されない場合に続行が有効になっていない、つまりチェックされていないことます。以下を参照してください。

コードで処理されない場合、継続しない（つまり、中断する）と効果的に言っている

これをする：

1. 気になる例外または一連の例外を右クリックします（つまり、通常、ツリーの一番上の行「共通言語ランタイム例外」）。
2. [ ユーザーコードで処理されない場合に続行する ]オプションを選択します（以下を参照）
3. 例外がチェックされていないことを確認します（以下を参照）
4. デバッグを続ける

それでうまくいきました-再び幸せです。

これはVS 2015でした

Visual Studioには間違いなくいくつかのバグがあり、再起動を必要とするスタックが発生します。VS2015。

私はシングルスレッドの状況でした NullReferenceExceptionときにブレークするように要求したにもかかわらず、「外部」ハンドラー（まだコード内にあります）に引っ掛かっ。

これは「処理された」例外であり、あなたは「処理されていない」例外を話していることに気づきますが、IISRESETで解決しない場合は、VSをすばやく再起動するとこれが修正されることがあります。

Visual Studio 2017はエラー処理で問題なく動作します。一方、Visual Studio 2015は、タスクでのエラー処理に夢中です。デバッグモードでは、非同期タスクで発生するすべての例外がキャッチされますが、ステップオーバーすると、無期限にハングするだけです。デバッグせずに実行すると、例外がキャッチされずに無期限にハングします!!! 私はビジュアルスタジオが大好きで、1995年から使用しています。2010年から2015年に直接ジャンプしましたが、2015年の方がはるかに悪いバージョンです。この例外処理を成功させるために8時間費やしました。正確なコードを自宅のコンピューターの2017にコピーしましたが、完全に機能しました。Microsoftが2015コンパイラーが正しく処理できないフレームワークにタスクをプッシュしたことに非常にイライラしています。