115

Visual studio used to have a specific checkbox to "Break on Un-handled exception". In 2015 this has been removed (or moved somewhere I cannot find it). So now my converted projects no longer break if I fail to provide a user-level exception handler. I don't want to break on all "thrown exceptions" because I handle specific ones. Just where I fail to provide a specific handler.

Right now my code simply exits the current procedure and continues execution at the next call stack location, NOT GOOD.

Anyone know how to get this back in Visual Studio 2015? I just upgraded to the community edition yesterday.

Zanon
  • 29,231
  • 20
  • 113
  • 126
Ted Lowery
  • 1,535
  • 2
  • 13
  • 8
  • Visual Studio 2015 will keep the current layout from your previous version, should it not the `Tool` or `Window` tab will have all the desired locations. In your case your looking for *Exception Settings*. – Greg Jul 21 '15 at 20:36
  • 4
    @greg, it's not that I don't know where to find the panel. My concern is the behaviour I am looking for is not in that panel. – Ted Lowery Jul 21 '15 at 20:40
  • same problem here. In our case we expect a exception break when autofac doesn't have all the types registered. Using the same solution with vs2013 it works, in vs2015 we get nothing. this is also a problem with other third party registrations and exceptions (like nservicebus).I wonder if it only is the case for project created in vs2013 and ran in vs2015 – Choco Smith Oct 13 '15 at 09:29
  • 3
    That new tool window really sucks. – cedd Oct 20 '15 at 09:24
  • According to [MS Classifications of Exceptions](https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/07/understanding-exceptions-while-debugging-with-visual-studio/) if you have *unhandled* exception it always breaks the debugger. May be you have to check the option "Break when excptions cross AppDomain ..." in the "Options -> Debugging -> General" list. – tsul Mar 04 '16 at 11:33
  • I am getting a "System.AccessViolationException" on "Frame.Navigate(typeof(Page2));" Has anyone been able to fix this? – yalematta Apr 10 '16 at 06:08

12 Answers12

120

There's a new window called "Exception Settings" that appears in the lower right pane by default when you begin debugging. It has all of the options you would expect.

You can bring it up with CTRL+ALT+E

This allows you to cherry-pick which exceptions cause a break in the debugger.

The key, though, is that you can also set whether these exceptions always break, or only break when it's an unhandled exception -- but setting this is not very intuitive.

You will need to first check "Enable Just My Code" under Tools > Options > Debugging.

This then allows you to right-click the column header (Break When Thrown) in the new Exceptions Settings window, and add the "Additional Actions" column, which then allows you to set each exception as "Continue when unhandled in user code".

So just right-click an exception or an entire group and disable the "Continue when unhandled in user code" flag. Unfortunately, the "Additional Actions" column will show up empty which is the same as "Break when unhandled in user code".

enter image description here

More on this here:

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

helb
  • 7,609
  • 8
  • 36
  • 58
Tom Studee
  • 10,316
  • 4
  • 38
  • 42
  • 7
    Actually that window only has options for "break with thrown". That is not what I want. I want "break when unhandled". – Ted Lowery Jul 21 '15 at 20:35
  • @user1317759: This is the equivalent of the old Debug->Exceptions window. Give it a try, it behaves as the old did. – Tom Studee Jul 21 '15 at 20:36
  • see my previous comment. – Ted Lowery Jul 21 '15 at 20:38
  • It breaks by default on user-unhandled exceptions. Be sure you have "Just my Code" enabled. https://msdn.microsoft.com/en-us/library/dn457346.aspx – Tom Studee Jul 21 '15 at 20:43
  • 17
    and that is the problem. It does NOT break. as I said above, it exits (steps out) of the current procedure call and just starts executing the next line of code in the calling procedure. – Ted Lowery Jul 21 '15 at 20:45
  • 2
    and I DO have "Just My Code" enabled. – Ted Lowery Jul 21 '15 at 20:46
  • 19
    @TomStudee I have the same problem too. What I want is "Break when unhandled" but what I get is "Break when thrown". The question is: how to get "Break when unhandled"? – ogggre Aug 07 '15 at 12:39
  • This does not do the same thing. I have several places where exceptions can be expected, but are handled. It still breaks there. This is not the answer. – Joel Barsotti Jan 15 '16 at 20:46
  • @JoelBarsotti http://blogs.msdn.com/b/visualstudioalm/archive/2015/01/08/understanding-exceptions-while-debugging-with-visual-studio.aspx – Tom Studee Jan 16 '16 at 12:46
  • 1
    @TomStudee I just added some much-needed clarification, as you were missing the key setting that allows you to set exceptions to break only when unhandled. – Jerad Rose Mar 18 '16 at 16:09
  • @PéturIngiEgilsson it's now under right click on exception group – Alex Zhukovskiy Oct 24 '17 at 11:00
36

I had the same issue and I managed to solve this by doing this -

  1. Press Ctrl + Alt + e to bring up the Exception Settings window.
  2. Tick Common Language Runtime Exceptions. enter image description here

That's it!

I was inspired this post since I am using a x64 version of Windows.

Justin XL
  • 38,763
  • 7
  • 88
  • 133
  • 8
    That will cause it to break on all exceptions, even ones handled by user code. – carlin.scott Feb 22 '16 at 21:39
  • 1
    @carlin.scott, I believe you could manually uncheck the exceptions that are handled from the list. – Justin XL Feb 22 '16 at 21:54
  • 7
    @JustinXL The problem is, this is a list by exception type, not by whether it's handled or not. For example, there are times when `System.ArgumentException` is handled, and times when it's not. I only care about breaking when it's *not* handled. – Jerad Rose Mar 18 '16 at 15:54
  • 2
    @JeradRose **The debugger will always break when an exception is unhandled.** So like I said, if you want no break on handled exceptions, simply uncheck that exception types from the **Break When Thrown** list. – Justin XL Mar 21 '16 at 09:57
  • Even when checking everything it's not breaking on an exception :/ just exiting – Douglas Gaskell Jun 15 '17 at 19:19
10

For googler that wants to break only when the exception concerns their code, there is an option in Visual Studio 2015: Options->Debugging->General->Just My Code. Once checked, it allow to do not break when the exception is managed (thrown and catched) outside your code.

Olivier de Rivoyre
  • 1,579
  • 1
  • 18
  • 24
  • This saved me for another situation where VS2015 by some reason refused to enter some code. The code is "mine" but something triggered the "Just my code" flag. I guess there is a bug somewhere when running 2 instances of VS and a stand alone web server and probably some more. – LosManos May 18 '16 at 13:28
9

Microsoft have subtly changed the logic in the new exceptions window.

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

The key part being:

Important Notes

  • This new window contains all of the same functionality as the old modal dialog. No capabilities of the debugger have changed only the way you can access them
  • The debugger will always break when an exception is unhandled
  • The setting to change if the debugger breaks on user-unhandled exceptions has moved under a context menu
  • The menu location has moved to Debug -> Windows -> Exception Settings

However, if like me you have a Global Unhandled Exception Handler in your code then the second item on that list is key: For me, no exceptions will therefore be truly unhandled, which seems to be different from VS2013.

To get back the behaviour where VS breaks on unhandled exceptions, I had to tick all of the exception types I wanted to break on and then secondly ensure that the "Additional Options" (you may need to make this column visible*) for "Continue when unhandled in user code" was NOT set. The VS2015 logic does not seem to consider my Global Unhandled Exception Handler to be "handled in user code", so it does break on these; it doesn't break on caught exceptions though. This makes it work like VS2013 did.

*How to enable the "Additional Actions" column *How to enable the "Additional Actions" column

oatsoda
  • 2,088
  • 2
  • 26
  • 49
7

If I'm correctly reading between the lines here, the issue is that your exception is effectively 'disappearing' even though the default debugger behavior should break on unhandled exceptions.

If you have asynchronous methods, you may be running into this issue because exceptions not caught on a thread pool thread as part of a Task continuation are not considered unhandled exceptions. Rather, they are swallowed and stored with the Task.

For example, take a look at this code:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

If you run this program with the default debugger settings (stop on unhandled exceptions only), the debugger will not break. This is because the thread pool thread allocated to the continuation swallows the exception (passing it to the Task instance) and releases itself back to the pool.

Note that, in this case, the real issue is that the Task returned by Test() is never checked. If you have similar types of 'fire-and-forget' logic in your code, then you won't see the exceptions at the time they are thrown (even if they are 'unhandled' inside the method); the exception only shows up when you observe the Task by awaiting it, checking its Result or explicitly looking at its Exception.

This is just a guess, but I think it's likely you're observing something like this.

Dan Bryant
  • 27,329
  • 4
  • 56
  • 102
  • Although this may not be related to the op's issue is raises a very good point about exceptions raised in async routines. – Phil Cooper Nov 23 '16 at 10:07
  • Is there a way to make the debugger stop even though the exception is stored like that? – Lucas Nov 27 '17 at 19:30
  • @Lucas, Not that I'm aware of, though you can get close with some code changes. If your fire-and-forget method body has a try-catch block, you can add an explicit `Debugger.Break()` call. Alternately, you can add an explicit `Debugger.Break()` in the `TaskScheduler.UnobservedTaskException` handler, though the downside here is that this can fire much later than the original exception, as it happens on the finalizer thread when the Task gets cleaned up. In general you should endeavor to always observe Task results or at least have a try-catch block to log at the time of failure. – Dan Bryant Nov 27 '17 at 20:46
2

In my experience the exception settings in 2015 get thrown completely out of whack if you change anything.

On expect that if you until the parent group "CLR" then you shouldn't get any breaking execpt for unhandled. You'll always break if an exception goes unhandled. But, if you have the CLR group unticked, code inside a try...catch simply should not cause a break. That is NOT the case.

Solution: In the new exception settings toolbox, right-click and choose "restore default". Taadaaaa... It behaves normally again. Now don't screw with it.

Clint StLaurent
  • 1,238
  • 12
  • 11
1

Try following the instructions:

  1. In the Exception Settings window, open the context menu by right-clicking in window and then selecting Show Columns. (If you have turned off Just My Code, you will not see this command.)
  2. You should see a second column named Additional Actions. This column displays Continue when unhandled by user code on specific exceptions, meaning that the debugger does not break if that exception is not handled in user code but is handled in external code.
  3. You can change this setting either for a particular exception (select the exception, right-click, and select/deselect Continue when Unhandled in User Code) or for an entire category of exceptions (for example, all the Common Language Runtime exceptions).

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

Andrei
  • 109
  • 10
  • Absolutely agree. It is awful not to show this column by default. Spent much time to find it. Besided, what "*user unhandled exception*" means is rather unclear. I had my handler of a Task cancellation (somthing like `try { task.Wait(); } catch { ... }`) and OperationCanceledException in the task was considered unhandled in user code somehow. – tsul Mar 04 '16 at 11:41
1

It's all a bit confusing, and in my opinion not as good as the old exceptions dialog, but anyway.

If an exception is in the list and ticked then the debugger will break whenever the exception is thrown.

If an exception is unticked or not in the list then the debugger will only break when that exception type is user unhandled.

For example, in the screenshot below, the debugger will break whenever a System.AccessViolationException is thrown, but for all the other exceptions it will only break if the exception was user unhandled.

Visual studio 2015 exceptions tool window

cedd
  • 1,741
  • 1
  • 21
  • 34
1

When I upgraded to VS2015, I also had issues where exceptions used to "break" the application, but are now ignored and passed right over. There are times when we want our code to intentionally throw exceptions in places where we want the code to stop, rather than continue. We always use the phrase Throw New Exception("Message") to get our code to intentionally break:

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

With VS2015, the classic "System.Exception" is what is thrown when we say Throw New Exception. Therefore, we needed to check the "System.Exception" tick in the new Exception Settings:

Check the System.Exception Box

Once checked, our code did as expected.

J.Wyckoff
  • 11
  • 2
1

The solution is to this is semantically the opposite to what you think you are setting. You need to ensure that Continue when unhandled in user code is not enabled i.e. not checked as shown under the Additional Actions column in the Exception settings tab - see below:

you are effectively saying do not continue (i.e. break) when unhandled in code

Exception Settings window (Control+Alt+E)

To do this:

  1. Right click the exception or set of exceptions that you care about (i.e. usually the top line 'Common Language Runtime Exceptions' in the tree)
  2. Select the option Continue When Unhandled in User Code (see below)
  3. Ensure that the exceptions are not checked (see below)
  4. continue debugging

enter image description here

That did it for me - happy again.

This was in VS 2015

Simon Sanderson
  • 2,939
  • 2
  • 19
  • 11
0

There's definitely some bug in Visual Studio that can cause it to get stuck requiring a restart. Even VS2015.

I had a single threaded situation where a NullReferenceException was getting caught by an 'outer' handler (still in my code) even though I asked for it to break when it was raised.

I realize this is a 'handled' exception and you're talking an 'unhandled' one - however I'm pretty sure that sometimes a quick restart of VS will fix this, if IISRESET doesn't.

Simon_Weaver
  • 140,023
  • 84
  • 646
  • 689
0

Visual Studio 2017 works just fine with error handling. Visual Studio 2015 on the other hand sucks at error handling with tasks because in debug mode all exceptions that occur in an async task are caught but then if I step over it just hangs indefinitely. If executed without debugging it hangs indefinitely with no exception caught!!! I love visual studio and have been using it since 1995 and 2015 is the worse version by far though I jumped from 2010 directly to 2015. I spent 8 hours trying to get this exception handling working with no success. I copied the exact code to 2017 on my home computer and it worked perfectly. I am very irritated that Microsoft pushed tasks into a framework that the 2015 compiler can't handle correctly.

Moses
  • 78
  • 6