I'm going around in circles here.
In plain-speak, English please, what in the heck is:
A first chance exception of type 'System.TypeInitializationException'
I'm trying to create an application that has a NumericUpDown control.
I double click the control and get:
Private
Sub NumericUpDown1_ValueChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles NumericUpDown1.ValueChanged End Sub
As soon as I try to debug, I get the "A first chance exception of type 'System.TypeInitializationException' " error.
In fact, I notice that in all my subs if I step through my program, I get the same errors throughout my whole application. Before I get into what I'm trying to do, I just want to understand the "what, why and how" I'm getting this error. I've gone to several pages on the MSDN site and am nowhere closer to understanding this than I am now. Without "geek-speak" and in plain English, why am I getting this error Sounds bad, but nothing I'm reading is making a bit of sense.
A) What is a "first chance exception"
B) Why and how do you get first chance exceptions
C) How does the first chance exception relate to System.TypeInitializationException and what is it
Thank you
Ted
In "English" please "A first chance exception of type System.TypeInitializationException"
Silvercat
hani1426
Many many thanks! That does explain it well then. What was confusing me is that the application is performing well otherwise.
Great answer and thanks!
Ted
Ivan Scattergood
A First Chance Exception is a debugging tool that only occurs when you run a program within a debugger.
The idea of a First Chance Exception is to give you the "first chance" to look at the exception before any exception handler steps in. You get to see the exception where it happened before any exception handler has messed about with it. You as the person debugging the program get first chance to look at the exception before the program you are debugging gets to look at it.
One important thing to note is that a First Chance Exception is not necessarily a symptom of a problem. For example, the IsBadReadPtr works by 'reading' the memory pointed to by the pointer and catching any access violation exception that is thrown. The catch block returns true to indicate that you are not allowed to read the memory pointed to.
If you run a program that calls IsBadReadPtr in a debugger, you'll get a First Chance Exception when the access violation happens. In a real debugging situation, this would allow you to examine the exception thrown in context. If you break and then press F5 to continue running, the IsBadReadPtr catch block will handle that exception and return 'true'. The program is working correctly and nothing bad happened.
On the other hand, if you run a program that dereferences your own badly initialised pointer inside a debugger you will also get a First Chance Exception. If you break and then press F5 to continue and if your program does not have a suitable catch block to handle the exception thrown, then your debugger will see a Second Chance Exception (or unhandled exception).
The following C++ code when compiled for debug and run inside the debugger demonstrates both cases
int * badPtr = (int *)1; // first chance but no second (unhandled) chance
if (IsBadReadPtr (badPtr, 1))
{
printf ("bad pointer");
}
else
{
printf ("good pointer");
} // First and second (unhandled) chance
int j;
j = *badPtr;
If you don;t want to be bothered by First Chance Exceptions you can use Debug | Exceptions menu to ignore the exception when thrown so that the debugger only pays attention to the exception if it is not handled by the user code.
The TypeInitializationException exception indicates that the type's class initializer (constuctor) threw an exception. Excerption.TypeName and Exception.TargetSite should tell you which type and which constructor. Exception.InnerException should tell you what the original exception was.
ChaitanyNaveen