When I testing my code with OCUnit, it makes exception log and makes it fail, but never stop when the exception raises. Even the breakpoint doesn't work.
I want to track the stack and see the state at the time of exception, but debugger doesn't pop up. How can I debug test code like regular code?
Set an exception breakpoint on the project.
Go to the Breakpoint tab on the left pane of XCode. It looks like an arrow pointing Right.
Then at the bottom of that screen click the + and Add Exception Breakpoint...
Related
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.
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.
When something throws an exception I usually click on "View details" which brings the QuickWatch window into the foreground and let's me examine the occurred exception.
What really bugs me is that I am not able to browse/search through my code having the QuickWatch window open next to it. I first have to close the window.
Is there a way to keep the window open when in break? Maybe there is another approach?
Is there a way to keep the window open when in break? Maybe there is
another approach?
Actually, there is no such function to browse or search the source code when you call Quick Watch window. And when you call the Quick Window, it will lock the current interface and we cannot do any other operation on other window. And this is the Quick Window feature in Debug mode.
Is there a way to keep the window open when in break? Maybe there is
another approach?
In fact, there is no such function to achieve your goal. Detecting exceptions is the job of the Debug mode process. If Debug mode is broken, the exception cannot be monitored, so it cannot be implemented. It must be based on Debug mode to capture.
As a suggestion, you can try this:
Suggestion
1) When you achieve the Error Exception User Unhandled under Debug mode, you can first browse/search through your code in Code Editor.
2) After that, you can keep the current interface of your code section, open Quick Watch Window(Debug-->QuickWatch)-->input $exception in the Expression textbox and click Reevaluate.
And this will be the same as shown earlier.
I am using the GHS MULTI Debugger to debug an integrity project for an embedded application. Does anyone know how to configure a stop on throw for this debugger like you can do in GDB? I want to have it break when an exception is thrown. (I know the majority of SO does not develop Integrity projects or use the MULTI debugger, but I thought I would throw this out there to see if any other Integrity developers might know).
For this example let's assume your Integrity project is named Test.gpj.
Before compiling your code, edit your Test.int file in a text editor and change the "StartIt" value to false. This will prevent the executable from starting immediately when it is loaded.
Then in the simulator (or on the target), when you load your executable, start debugging it with the Test_as0 file.
In the Multi Command line, enter:
e __throw
Set a breakpoint on the beginning of this function (set the breakpoint to be an any task break point).
Repeat this also for the __rethrow function.
Now, when an unhandled exception occurs when your executable is running, it will hit one of these break points. You can then navigate the call stack and see where this exception is occurring. (There is an option in the Debugger GUI to navigate up and down the stack frames). Alternatively you can enter:
Ctrl + + and Ctrl + - will navigate up and down the stack frames to find where the exception was encountered.
I have a piece of code in C# that's essentially like the following...
WriteFile();
try {
RunTest();
} finally {
DeleteFile();
}
Now this has been planned so that even on failure, it cleans up the files it left behind. This works when not run in debug mode (although it pops up a message asking if I want to debug the program or close it. Closing it produces the appropriate results).
When I run this in debug mode and hit an exception inside of RunTest, I only seem to have two options. In the first one, I tell debugging to stop. This is equivalent to killing the program and the block in finally does not run (so the file doesn't get deleted like it should). If I tell it to continue, it doesn't propogate the exception up and instead, it just hits an exception somewhere else.
Is there anyway to get debug mode to continue like a normal program after hitting an exception?
From the Debug menu, choose Exceptions (or use Ctrl + Alt + E). This will bring up a dialog where you can uncheck appropriate checkboxes in the "User-unhandled" column for exceptions which you don't want to stop at while debugging.
I believe that will make exception propagation work normally. And you can still set a breakpoint either in the try or finally block to see what's happening.
Check Debug/Exceptions if there are any exceptions set.
Another option would be to handle the event Application.ThreadException (Windows Forms) or Application.UnhandledException (Silverlight etc.) and tell the application to continue or exit, depending on the severity of your exception.