Develop Reference

How to stop Blazor from catching exceptions?

I develop a server-side Blazor application in Visual Studio, my application uses Kestrel web server.
I can use a debugger, I TRY to use it at least.
When I set any breakpoint in any point of my code, the breakpoint is hit, Visual Studio debugger is shown, everything works like in any other NORMAL .NET application.
What I try to achieve is investigate / debug an exception that is thrown in my C# code in Blazor application. Exactly - it's a component code. I click a button in my app UI, an event handler is called, it starts executing code, I can insert a break point, so VS stops the program execution and shows me the line with the breakpoint, variable values and all. It's weird I'm even explaining it.
However, if an exception occurs in my program, Visual Studio debugger is NOT shown. The exception is intercepted in Blazor and show to the console instead. It makes debugging of the application super tedious and annoying chore. It also increases development time like 10x, to say at least.
I'm almost sure Blazor cannot be as stupidly designed and there must be an option allowing to debug it normally, using debugger that is already connected and working. Catching errors and logging them to the console or other log makes sense for deployed / released application. For development, especially in debug session in Visual Studio - the exceptions should be sent to the debugger. So there must be an option to enable such basic behavior, am I right?
I bet on appsettings.json file.
I spent several hours trying to find that information on Google and Microsoft Docs, but it seems either I'm the first person in the world asking that, or I just cannot figure out the right question or...
I'm really the first person in the world trying to use Visual Studio debugger to debug exceptions in my code. I mean in Blazor. Because I searched for "Debugging exceptions in Visual Studio" and it returns obvious (at least for me) results, like pictures of VS debugger showing exceptions. But if I only add "Blazor" to the question, the results are just crazy and totally unrelated.
Fun fact: when using NavigationManager.NavigateTo("/Identity/Account/Login") in my code, Visual Studio actually stops on exception, that is not really exception. I mean Blazor devs on GitHub say, the exception is a normal way how it operates. Feature not bug. So, when my application doing a normal, expected thing and works totally properly - Visual Studio debugger is suddenly shown and I see exception I don't care for. When my program performs invalid operation (a REAL exception occurs) - Visual Studio debugger does not show. The event is hidden and I either have to guess what has happened, or write some extra code to investigate. If that's not crazy I don't know what is.
BTW, I know there are workarounds for it. I'm not interested. I can use Debug.Print, I can insert a breakpoint and analyze the executed code step by step. I just want the debugger to be run as intended, automatically without hiding exceptions.

It works as designed :) . Blazor, or any other asp.net framework has try/catch block somewhere in request handling flow. It's just to not terminate whole application if any exception is thrown. So exception is catched and you are not informed by debugger.
You can configure debugger to break when any exception is thrown. Look in docs.

Visual Studio 2017 Breaks on System.InvalidOperationException Even Though It Is Both Handled AND Unchecked In Exception Settings [duplicate]

Visual Studio 2017 is (kind of suddenly) breaking on all exceptions. That means, if I deactivate them in the exceptions settings (pressing CTRL + ALT + E while debugging), the debugger still breaks on them. I don't know wether this is just a bug of VS I can't change and therefore have to live with, or wether there is a simple solution for it.
This is the exception settings window:
and this the exception VS breaks on:
By the way, I also tried that beautiful minus (nothing happens if I press it) or adding a impossible condition (VS still broke on the exception).
I also tested other exceptions (by simply throwing them), which I deactivated before, and they get thrown as well and I tested the same issue in other projects, where it appeared as well:
I actually even put the whole stuff into a try catch statement but VS still breaks:
InitializeComponent ();
try
{
var t = new Thread (() =>
{
while (!IsHandleCreated) {} //It breaks here (similiar to the screenshots)
while (true)
Invoke (new Action (() => Size = new Size ()));
});
while (true)
{
t.Start ();
Thread.Sleep (100);
t.Abort ();
}
}
catch (ThreadAbortException) { }
It doesn't appear in other IDEs (like Rider) on my PC and doesn't occurr on other PCs in VS. It didn't always occurr on my PC, it just started recently and only in debugging mode. And if I continue the execution (with F5) it just continues normally.
EDIT As I put the try catch inside the thread it behaved a little bit different (I'm sorry for putting pictures in here, but I think they're more expressive in that case):
Can anybody explain this behaviour?
EDIT It seems to be normal for ThreadAbortExceptions to break again at the end of a catch statement. However, VS still shouldn't break on this exception at all.

I was having a similar problem.
I fixed it by unchecking "Break when exceptions cross AppDomain or managed/native boundaries" in Tools > Options > Debugging > General

I fixed it by unchecking Enable Just My Code in Tools > Options > Debugging > General

I can't confirm whether this happens with other project types, but it happens to me consistently with (Visual Studio Tools for Python) VSTP.
Although it is less than satisfactory, it can at least silence the exceptions and allow you to continue working in peace until a better solution surfaces. In my case, it was nearly impossible to debug my code, since StopIteration breaks during every iteration.
Select Debug > Windows > Exception Settings or press Ctrl-Alt-E. Y
Right click anywhere on the Window and select Show Columns > Additional Actions. You will have an "Additional Actions" column appear if it doesn't already.
Right click on a specific exception you want to silence or click the top level checkbox to select an entire category of exceptions, i.e. Python Exceptions. Click Continue When Unhandled in User Code.
Repeat for each additional exception or category of exceptions.

I know it's a little late for this, but ThreadAbortException is different from all other exceptions, and requires some special handling, otherwise it is automatically re-thrown at the end of all catch blocks if you don't actually handle it the way it's supposed to be handled.

Visual Studio 2015 break on unhandled exceptions not working

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.

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".
More on this here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

I had the same issue and I managed to solve this by doing this -
Press Ctrl + Alt + e to bring up
the Exception Settings window.
Tick Common Language Runtime Exceptions.
That's it!
I was inspired this post since I am using a x64 version of Windows.

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.

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

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.

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.

Try following the instructions:
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.)
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.
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

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.

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.

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
To do this:
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)
Select the option Continue When Unhandled in User Code (see below)
Ensure that the exceptions are not checked (see below)
continue debugging
That did it for me - happy again.
This was in VS 2015

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.

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.

How to configure Visual Studio 2010 to stop my program when a XamlParseException is thrown?

I'm using Visual Studio 2010, .NET 4.0. When I debug my program, it doesn't shows me the XamlParseException, but when I install my program and run it, the exception is thrown and my program stops working. How do I configure VS10 to show me the XamlParseException? How do I debug this exception?

How do I configure VS10 to show me the XamlParseException?
This question has already been answered but unfortunately using the solution provided will not solve your problem. Let me try to explain why:
In the Debug -> Exceptions dialog box you can turn on Break when an exception is either Thrown or User-unhandled and in this case you want to do this for System.Windows.Markup.XamlParseException. Normally, you will have User-unhandled checked. The setting only applies when your are running your application in the Visual Studio debugger, and when the setting is turned on the debugger will break in the code when the exception is thrown if there is not try-catch handler to catch the exception. This is very useful because you can inspect variables etc. at the point in your code when the error is discovered.
If you have a try-catch handler for your exception you might still want the debugger to break when the exception is thrown. In that case you have to check the Thrown check box for that to happen. This can be useful if you want to troubleshoot why and where a particular exception is thrown in an application that has exception handling (which most applications should have).
However, in your case you do not have exception handling for XamlParseException as you your "program stops working" and throws an XamlParseException. Running your application in the debugger should produce the same unhandled exception but it does not.
So you should change your question from "how do I configure the debugger to break when an exception is thrown?" to "why is XamlParseException thrown in my production environment and not when running in the debugger?"
Unfortunately, I do not have a good answer for the second question. For starters, getting more details about the exception would be useful as it will point to some XAML that fails to load. It should point to a XAML source file and position and may also have an inner exception with further information.
However, as the XAML is loaded by the runtime and not directly by your code it might be difficult to figure out where to place the catch handler for the XamlParseException. You might try the Application.DispatcherUnhandledException but that is not available on all platforms using XAML (you have not specified if you are using WPF, Silverlight etc.)

In Visual Studio menu you have Debug->Exceptions
Here you can configure the exceptions you want your debugger to stop at.
Verify that Common Language Runtime Exception is checked for Thrown column

Check you have the following option selected.

verdesrobert and blacai both answers the question you ask in the title, but that won't help you if as you say the code is the same. Normally your code would have crashed on the same exception in your debugging environment too, regardless of exception settings.
So clearly there's some kind of difference between your debugging environment and the production environment that causes this. What will help you is to narrow down these differences. For starters, you should try and log the exception's stack trace when it occurs in your deployed application, as well as the XAML code you are trying to parse.
This should give you a clue on how to reproduce the scenario in your environment and solve the problem once and for all. You can also log anything else that may be of interest: security context, runtime version, OS version, etc, etc...

in C# is there a way, in the debugger, to suppress a exception from breaking into the debugger?

I'm using VS2010 in C#
there is a place in my code where an exception is thrown and properly handled.
the problem is that I'd like to configure the debugger to break on all exceptions, handled or not - all exceptions but this one. My goal is to see all the thrown exceptions in the debugger, but this one exception is driving me bonkers as it hits somewhat often
I'd love some kind of #pragma trick?

Go to the Debug menu, select Exceptions.... Expand the Common Language Runtime Exceptions category and either uncheck the specific exception if it's there or if it's not, you can add it via the Add... button on the bottom right side (type in the full class name).

Look in the Visual Studio Debug menu under "Exceptions". The dialog that pops up should allow you to configure the type of behavior you're looking for.