I have client-server (Silverlight) app.
Some server code throws exceptions that I handle on client. When I debug - Visual Studion breaks on those exceptions and I have to hit "Continue". It really slows down development.
Is there any way to skip specific exceptions or deal with this somehow?
Debug Menu -> Exceptions (Ctrl + Alt + E) -> Find.. type the exception name, then untick the check boxes.
If it's your own exception, you can add it by clicking Add, select Common Language Runtime Exceptions and then putting in the fully qualified name of the exception. Then untick the boxes.
See How to: Correct Run-Time Errors with the Exception Assistant
Basically you can disable checkbox "Enable the exception assistant" under the Visual Studio menu:
-> Debug
-> Options and Settings
-> Debugging
-> General
Also it could be that you've checked specific exception types to be handled so check it under the Visual Studio menu:
-> Debug
-> Exceptions
In visual studio, the Debug menu -> Exceptions. You can check and uncheck exceptions. You can have it break on handled thrown ones, or unhandled ones.
Also, if your exceptions are custom, they won't appear in there by default (only CLR exceptions are there). You can add them using the same window, be sure to use the fully qualified name for the exception (namespace and all)
It happened to me once when i was debugging a code and it will show a Continue button and will never go inside the exception. The error that i was having is like i was creating and instances before the InitializeComponent() was called. I think this can help you to find what you are doing before that.
Related
I have a set of NUnit tests (running using the Resharper test runner), and some of those fail due to assertion exceptions happening in background threads; and when this happens VS2017 breaks into the debugger, what is undesirable as I want it to keep on running other tests.
All the settings in "Exception Settings/CLR/Thrown" are turned off.
The "User-Unhandled" settings in that dialog aren't present whether I switch the "Just My Code" option on or off
All the "Exception Settings/Managed Debugging Assistants" settings are turned off.
Any other ideas how to prevent it from breaking on those exceptions?
The first thing I'll mention is that assertion exceptions shouldn't be propagating out of your testing framework. If they are, then it could be because of some sneaky code that I can't conceive of. In other words, all assertion exceptions are inherently "handled", because your test framework will handle them for you.
There is also a concept of running vs. debugging a test. If your intention is to simply ignore all exceptions everywhere in your tests, then you should just choose to run - and VS will not attach the debugger at all (and then can't break). I don't know what this difference looks like in resharper's test runner, but in VS it's under the Test > Run and Test > Debug menu respectively.
If you can't re-architect your tests, and you want to be debugging other exceptions (just not assertion exceptions) or you want to hit break points, read the following:
By default, the new debugger (2015+) will break when an exception is un-handled - but you can turn this behaviour off for all exceptions or just a specific one.
Open the exception settings window (Debug > Windows > Exception Settings)
Right click on "Common Language Runtime Exceptions" (or the specific exception you want to change)
In the right click menu click "Continue When Unhandled in User Code".
You should now see a the text "Continue when unhandled in user code" on the right hand side of the window under the "Additional Actions" column and VS should no longer break.
Apparently, this was a bug in Visual Studio. Installing the later updates has fixed it.
In the previous versions of VS, if I have an error in my code and there was no exception handling - in debug mode - the debugger stops on the faulty code line, e.g. in case of an ArgumentOutOfRangeException.
But now the debugger only stops in the app.g.i.cs file where I have an UnhandledException handler.
What should I set to get back the old behaviour?
control, alt + E to bring up exceptions, then check Common Language Runtime Exceptions thrown column. This will then break where the exception occurs rather than where it's handled.
You have to add Common Language Runtime Exceptions in the Exceptions settings. Debug > Windows > Exception settings.
you can find more about it here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx
On debug mode, press Ctrl+E to show Exception tab. In Exception tab on debug mode, you'll see "Common Language Runtime Exceptions" check box. And click on it to make it checked. Run your application on debug mode. You'll see that the IDE will stop on error line. Take care!
How can i disable the "checking for solution" when a error occurs in my program?
What i want is that it directly goes to the error inside Visual Studio 2010. Now i have to wait like 1 minute before i can select debug and see my error.
Did not have this behavior before and not really sure what changed in the environmental settings.
I was debugging with 2 breakpoints when this behavior occurs every time a error happens outside the breakpoints.
This is a settings of the OS rather than of Visual Studio, to disable checking for solution feature on Windows 7 :
Click on start, type: Choose how to report problems, then change it to Never check for solutions .
If Visual Studio stops reponding it shows "Checking for solution".
At this stage VS is trying to fix the problem and promts to "send report" if user allows that.
It makes not so much sense to disable this, nor it is allowed in Visual Studio.
What if you put a tick on the check box:
Debug -> Exception -> Common Language Runtime Exceptions?
Does it stop immediately?
I've started working on an old project, where WinForms application uses DevExpress controls, for example DataGrid.
The program window contains another multiple windows, and when I'm minimizing some of them, I get an Unhandled Application Exception with Attempted to divide by zero. in details. I want to know what causes this exception, but when I run the project in Debug mode in Visual Studio (2005 version), it does not react in any way to this exception.
Is there a way to find out the reason this exception is thrown?
Enable such exceptions in
Debug -> Exceptions -> Common Language Runtime Exceptions
Also
Also, it is a good idea to turn off the Tools-->Options-->Debugging-->Enable Just My Code option.
I have a TextBox in which I validate the input with a third party library. However, this library throws custom exceptions when the syntax is incorrect. This is not a real big deal, except for when you are debugging.
When debugging, since the text in the TextBox will always be initially wrong (I am still typing it), the debugger will stop after each letter until it is correct, which is really annoying as I validate with each letter.
How can I tell the debugger to not break at these custom exceptions?
P.S. I have already tried to filter the Debug -> Exceptions (added it in Common Language Runtime Exceptions), but this did not work for me. The debugger still stops at the line where the library is called.
P.P.S. Using Visual Studio 2010.
Answer:
In the end I was very close with my PS. It was a pretty silly mistake: I had a typo in the namespace. Thanks to Pop Catalin and Madhur Ahuja for pointing it out!
There is an 'exceptions' window in
Visual Studio ... try Ctrl-Alt-E when
debugging and click on the 'Thrown'
checkbox for the exception you want to
stop on
You are looking for reverse of this:
Visual Studio: How to break on handled exceptions?
Assuming you want to break when the exception occurs unexpected you really should hide the method from the debugger using the [System.Diagnostics.DebuggerHidden] method.
Debug + Exceptions, click the Add Button. Set the type to "Common Language Runtime Exceptions" and the Name to the full name of the custom exception, including the namespace name. You can now untick the Thrown box for this one, expand the node first if necessary.
This worked for me: [DebuggerHidden]
This is not a bug in the debugger, it was a intentional change. While
the behavior is different and can be confusing, it had to be changed
in Visual Studio 2010 to support several other scenarios including
Silverlight debugging.
Disable "break on user unhandled exceptions" for the exception types you you are encountering here (via Debug -> Exceptions)
Disable "break on user unhandled exceptions" for all exceptions (via Debug -> Exceptions)
For more details please refer the link here.
Breaking on exceptions in VS2010