I am debuggin a subtle bug that is thrown from a .net custom component (no source and obfuscated). The component throws a NullReferenceException in its OnPaint() method which makes calls to subscribers, including my code. I am 100% sure that the problem is in my code. The problem is that visual studio debugger does not stop at the point where the exception is thrown, as it should (I enabled NullReferenceException in the Debug/Exceptions dialog).
This is the first time I encountered such a problem in visual studio. Any ideas on identifying offending code, please?
Kemal
Likely the problem is your code isn't throwing the NullReferenceException, however it is probably returning null at some point. You could try adding guard conditions at the end of your functions that ensure you are not returning null, such as an Debug.Assert(retVal != null, "Returned null in function").
If you are sure you own code is throwing a NullReferenceException, make sure you turn on thrown exceptions, rather than user-unhandled ones.
Related
For some reason, when attempting to debug an application, the exceptions themselves show as null. Initially, I didn't have the SqlException catch section, but I did see that it said it had thrown a SqlException, so figured I'd add to look and the result appears the same.
I did previously remove Visual Studio and reinstalled it (plus the 1.1 asp.net core SDK) so that's the oddball difference between now and before. It is running in Debug.
How do I get it to return the actual error messages so I can debug?
If your cursor is on the catch clause, the exception will be null. Hit F10 to see it's content.
I just came across odd behavior with exception handling in .Net. (I'm using C# in MS Visual Studio 2008, but one question I saw here seemed to imply that what I see is true throughout the .Net world.) I am writing a plain WinForm application. I am intentionally causing an unhandled exception to be thrown inside a form_load event handler, outside of any try block. I get no notification. If an unhandled exception occurs in a normal method, a message pops up telling me that the exception happened, and giving me some information about the problem. But in the handler, the code just quietly exits the function without letting anybody know that it happened. If I add a try/catch block, the exception is caught as expected.
Is it true that this behavior happens in all event handlers? And is this expected behavior? And if so, is it because there is too much danger of bad things happening if an event handler unexpectedly stops?
Whether inside or outside VS, this behavior occurs when there is a debugger attached to the process. However, being a debug version makes no difference. If running outside VS without a debugger attached, the unhandled exception will fire up.
You can check
Why the form load can't catch exception? , and
VS2010 does not show unhandled exception message in a WinForms Application on a 64-bit version of Windows , for possible solutions.
EDIT: This behavior is only specific to the form_load event handler, as far as I know.
Has anyone else ever seen this happen? I've had Visual Studio crash over and over again when typing in an object initializer: https://msdn.microsoft.com/en-us/library/bb384062.aspx
I suspect it's some kind of Intellisense bug, since it seems to occur only when the space or period key is pressed. I'm really curious what's triggering the sudden and reproducible crash and if there's any patches or workaround to prevent it from occurring.
The image shows where the cursor is when typing within the first set of brackets. This code appears in a method, which implements an interface member for the class.
This appears to have been caused by the "HideShow Comments" extension. I'm still not sure why it occurs, but disabling the plugin stops the crash from occurring and re-enabling the extension causes the crash to occur again. This must be a problem with Visual Studio itself, since it's the only common denominator in all these extension-related crashes.
I attached a debugger and caught the following error:
An unhandled exception of type 'System.NullReferenceException'
occurred in HideShow.Implementation. Additional information: Object
reference not set to an instance of an object.
I test the exceptions interception, so, I don't need that Visual Studio breaks on thinkgs like thrown new NullReferenceException("myVar").
I have the following under Debug=>Exceptions
however, VS breaks on the exceptions. What should I do?
PS.
for the application unhandled exception, I "catch" them using the Application.UnhandledException as in the the following:
''' <summary>Occurs when the application encounters an unhandled exception.</summary> '
Private Sub Application_UnhandledException(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) Handles Me.UnhandledException
Dim message As String = String.Format("An application UnhandledException were thrown.{1}The application will now terminate.{1}'{0}'{1}{1}StackTrace:{1}{2}", e.Exception.Message, Environment.NewLine, e.Exception.StackTrace)
MessageBox.Show(message)
End Sub
I had same problem when I started using VS2010. I have unit tests, which expect exceptions, and I throw exceptions from my functions. These exceptions are supposed to be handled by the user of my library. In Debug->Exceptions dialog, I unchecked check box under User-Unhandled column for Common Language Runtime Exceptions, and VS stopped breaking on these exceptions. By the way, I don't see second column in the dialog you attached here.
If you throw an exception that is not handled anywhere in your code, Visual Studio is going to break. It doesn't have any other choice: there was an unhandled exception. Outside of Visual Studio, the application would show an error message and inform the user that an unhandled exception occurred.
The options you see in the Debug -> Exceptions dialog only allow you to configure whether Visual Studio breaks on all exceptions, including those that are later handled in your code. These are often referred to as "first-chance" exceptions.
Beyond that, you should never throw a NullReferenceException yourself; this is a runtime exception that is reserved for the runtime framework. Instead, you should throw an ArgumentNullException.
The below method works for me in Visual Studio 2015 (a similar process may work for VS2010).
Taken from the Visual Studio documentation on managing exceptions with the debugger:
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).
In my code I had an error that was catched by following exceptions while program was running. However when I was running program in Visual Studio when the error was happening application was simply exiting without any error (other errors usually bring me to the problematic line).
if (ApplicationDeployment.IsNetworkDeployed) {
AppDomain.CurrentDomain.UnhandledException += currentDomainUnhandledException;
Application.ThreadException += applicationThreadException;
}
Of course if i remove the if i get this exception handling done by my methods which simply uses MessageBox to show the error. Is there a way to force Visual Studio to catch this error like it catches other types of errors?
Only by using Debug + Exceptions, Thrown checkbox. That makes the debugger stop on the "first chance". At the point the exception is thrown. You typically want to do this:
if (!System.Diagnostics.Debugger.IsAttached) {
// Subscribe the events
//...
}
Note that this already works that way for Application.ThreadException, Winforms already avoids catching exceptions if it sees a debugger. For the exact same reason.