While debugging in ASP.NET Core w/ VS 2019, when I have break on exceptions turned on 🟢, I break on the throwing, which is what I want 👍, but then I have to continue, F5 through each pop of the stack 🔁.
how do I say "CONTINUE out of this request & let the exception bubble up to the top w/o breaking"? is that an option in VS?
As the ASP.NET Core app is a long-running process, VS has no way of knowing where & when a request starts and ends. You can disable all breakpoints, hit F5, then re-enable them for the next request.
Use the top menu: Debug > Disable All Breakpoints
Use Breakpoints panel
You always can set a hotkey to speed up this workflow
I do believe that what you're seeing is the exception being rethrown on every async stack frame. You could confirm this if the exception dialog says that you can suppress the exception when thrown from System.Private.CoreLib.dll assembly, even though it was originally thrown in your code.
If you disable Just My Code, you should see that the exception is thrown from ExceptionDispatchInfo, which is the type used to rethrow exceptions with their original call stack in async/await. This is also what causes these exceptions to be thrown from System.Private.CoreLib.dll.
The only way I have found to improve this is to not break when the exception is thrown from System, either by using exception filter with module parameter, or in exception dialog > Exception Settings. This is only valid for exceptions that you never encounter from System.Private.CoreLib.dll. I am also not sure how this would work for Just My Code and external libraries as an exception might reach your code only after redispatch from async/await machinery.
With that in mind, you'll often just have to F5 all the way or rely more on breakpoints instead of exceptions for debugging.
Alternatively, as hinted in the other answer, you could disable exceptions until the request completes and re-enable them.
Related
Just installed VS2019 and noticed one uncomfortable thing: in Debug it stops ("falls") at the each exception, even inside try sections. How can I force it to ignore these exceptions, go to catch and work further?
After answer of Perry Qian-MSFT. Now I see this when I have UNHANDLED exception.
Translation: "application is in pause mode". And call stack is empty.
How to force VS2019 ignore exceptions inside “try” section
First, I agree with dixv and thanks for his help.
Current VS IDE can ignore specific exceptions as required.Under Debug-->Windows-->Exception settings
You can record the previous exception's name and search under it and then uncheck it.
Note
After that, please uncheck Just My Code option, otherwise the exception may still be interrupted.
Tools-->Options-->Debugging-->General-->Just My Code
Update 1
If you enable that feature and also want to see the detailed info about that exception without breaking Debugging, you can add these code in catch
try
{
xxxxxxxxxxxxxxx
}
catch (Exception e) {
Debug.WriteLine("=============================");
Debug.WriteLine(e.Message);
Debug.WriteLine(e.Source);
Debug.WriteLine(e.StackTrace);
Debug.WriteLine("=============================");
}
It will show the specific info about that exception in output window:
More info, you can refer to this issue.
Update 2
When you face that situation, you can just click on View Detail of that exception window, it will call Watch Widow and then when you click on StackTrace, it will show the related error file name and related line to you.
Hope it will help you.
Appears, there're two possible ways to... not solve this issue, but at least make it less uncomfortable.
1) Update 2 from Perry Qian-MSFT
2) I enabled Diagnostic Tools while debugging and when exception appears, I just select it in the log of the DiagTools and VS shows me required line.
You probably have the debugger set to break on first chance exceptions, which means it will break when the exception is thrown regardless of any code to catch it. To prevent this behavior, uncheck the respective exception types under Debug / Windows / Exception Settings.
From Manage exceptions with the debugger in Visual Studio:
The debugger can break execution at the point where an exception is thrown, so you may examine the exception before a handler is invoked. [...]
If you select an exception in the Exception Settings window, debugger execution will break wherever the exception is thrown, no matter whether it's handled. Now the exception is called a first chance exception.
On my other machines, Visual Studio always broke on errors when there was not a try/catch to handle them, but if there was a try/catch then it didn't break.
For some reason, on this laptop, it doesn't work that way. It didn't break at all at first, but then I found out how to set it to break by going to debug/exceptions. However, configuring it to break there causes it to always break on exceptions even if there is a try/catch block.
How do I make it work like I'm used to?
Make sure you have Just My Code Enabled by going into Tools-->Options-->Debugger-->General--> Enable Just My Code. This will change your Debug--> Exceptions Dialog Box to show a CheckBox for User-unhandled Errors.
I cannot find the dialogue in the accepted answer.
In my experience, in Exception Settings, if you hit "Restore the list to default settings", it will not break on exceptions you handled. If you checked a particular exception in Exception Settings, then it will break regardless of whether you handles this exception in your code or not.
For a more updated answer:
When you go to the exception settings right click on the exception type you want, which for C# would probably be Common Language Runtime Exceptions, and enable the "Continue When Unhandled in User Code" setting.
For me this seemed to not break on exceptions that were handled in a try catch or otherwise, but it did break when an unhandled exception occurred. The naming of the option makes it feel a bit iffy but it seems to work exactly as you and I hoped now.
Exception settings
Enable the required setting
In Visual Studio 2022 in the Exception Settings (Debug > Windows > Exception Settings), there is another column (Additional Actions) that can be viewed. It is written about here in the Microsoft Docs.
Make sure to remove the "Continue when unhandled in user code" setting in order break on any given exception.
I'm working on a project where a lot of bad code is written.
Today I came across a piece of code that caught and exception and just returned an empty string to "handle" it (very difficult to debug).
I was wondering whether there was any way of knowing that an exception has been thrown and caught in visual studio 2010?
VS menu -> Debug -> Exceptions -> Enable CLR Exceptions
(CTRL+ALT+E)
There you can choose from "Thrown" or "user un-handled", obviously you need to break on "Thrown" exceptions
The debugger can break execution of your application immediately when
an exception occurs, giving you a chance to debug the exception before
a handler is invoked.
More details on MSDN: How to: Break When an Exception is Thrown
Important note - this feature is not available on Visual Studio "Web Developer" edition
Go to the 'debug' menu, select 'exceptions' and check 'Thrown' next to Common Language Runtime Exceptions. When debugging, this will break at any point an exception is thrown when debugging.
On the "Debug" menu choose "Exceptions..." and then tick "Thrown" and/or "User-Unhandled" for Common Language Runtime Exceptions.
This is not possible.
Visual Studio has settings for stopping either when unhandled exceptions occur or whenever an exception is thrown (or both).
There is no setting for exceptions that have been caught (as this would be a very common case and would overwhelm the display).
The debugger writes a entry to the output window when an exception is thrown.
http://msdn.microsoft.com/en-us/library/x85tt0dd.aspx
You can break when an exception is thrown.
You can use ReSharper to detect unused parameters (catch(Exception e))
My vs2010 shows this message when an exception is thrown:
How can I configure the debugger to show exceptions like this instead:
Thanks!
Big difference between the two. You'll only see the first one when you explicitly configure the debugger to stop when an exception is thrown. You do so with Debug + Exceptions, Thrown checkbox. You don't often use this, really only when your code contains too many catch statements that swallow exceptions inappropriately and making the code misbehave. It also has a knack for showing exceptions in code you didn't write. Click the Break button to allow the debugger to show you the details.
You'll only get the second screenshot when an exception is thrown and there is no catch block to catch it, making it an unhandled exception. That's a fatal error, the program cannot continue. The debugger stops to show you the problem, it is otherwise the end of the debugging session. Without a debugger your program will crash. This is the 'good' kind, you get it by omitting try/catch blocks so your program terminates when something unexpected happens. You will want to write an event handler for the AppDomain.CurrentDomain.UnhandledException event so the user at least has an idea what went wrong. And you for that matter.
Is there a pragma or debugger attribute which will allow the debugger to not break on the throwing of a specific exception even though under the Debug >> Exceptions menu I've told it to break when any CLR Exceptions are throw?
In general while developing I like to have it break on exceptions while debugging so that I can immediately inspect them. Sometimes there are some isolated cases where it is known that this block of code occasionally throws exceptions and I've handled it in with a try-catch. See the answer to this question where the consensus was that try-catch is the most correct situation.
I'd like to be able to set an attribute on the method (something analogous to System.Diagnostics.DebuggerHiddenAttribute) which just ignores any exceptions thrown in the method.
BTW, I'm currently experiencing this in Visual Studio 2008, but I'm guessing there is either an answer for all versions or none.
The direct answer can be found under Exceptions menu item of the Debug menu. This is a per solution/project setting. (Tools > Option > Debugging is a system-wide setting.) See the help topic Visual Studio Debugger, How to: Break When an Exception is Thrown at http://msdn.microsoft.com/en-us/library/d14azbfh.aspx for details. The Exceptions dialog allows you to set which exceptions are thrown or which exceptions break into the debugger.
I find I get more use out of the DebuggerStepThrough attribute.
In general, I leave throwing exceptions to the default (Debug > Exceptions user-unhandled checked and Thrown unchecked) and add the DebuggerStepThrough attribute for methods where I am not interested in stepping through nor am I interested in any exceptions being thrown within that method. I rarely use DebuggerHidden, and get more use with DebuggerNonUserCode in library code.