Exception confusion

[peter_m]

Hi

I can't figure out why an exception is not trapped by an unhandled
exception handler and would appreciate some help.

My Windows Forms project has the Application Framework enabled and
includes the following event handler:

Private Sub AppUnhandledException(ByVal sender As Object, ByVal e As
Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs)
Handles Me.UnhandledException

'My code

End Sub

One of the Forms in the project includes a User Control that I've
written which contains a number of properties. If a Property value is
out of range an ArgumentException is thrown.

The code that loads the User Control's properties IS NOT included
within a Try Catch block. I was expecting that if a property value is
incorrect the ArgumentException thrown would be caught and reported by
the AppUnhandledException handler shown above. Instead what happens
is a "First chance ... ArgumentException" is reported in Visual
Studio's Output window but the AppUnhandledException handler is not
entered.

If I wrap the call to the User Control's property in a Try Catch block
the ArgumentException is caught. However, I don't want to have to
wrap every call to a property procedure (or group of property
procedures) in a Try Catch block as these seems inefficient.

Can someone help me diagnose why my unhandles eception handler is not
working. Thanks.

Peter,

 

[Cor Ligthert[MVP]]

Peter,

As your code is only

End Sub then it sure won't work

Cor

 

[peter_m]

Peter,

As your code is only

End Sub then it sure won't work

Cor
















- Show quoted text -

Cor

I only added the AppUnhandledException declaration to show how the
event handler was defined. The "My code" comment between the Sub and
End Sub was meant to represent some real code that logs details of the
exception.

Also - I forgot to mention that my User Control is within a Class
Library project and not within the Windows Application project that
contains the Form which the User Control is sited upon. Can you tell
me is the User Control created on a different thread when it's
implemented in this way?

Peter,

 

[Phill W.]

The code that loads the User Control's properties IS NOT included
within a Try Catch block. I was expecting that if a property value is
incorrect the ArgumentException thrown would be caught and reported by
the AppUnhandledException handler shown above.

I may be wrong here, but isn't that handler intended for trapping and
reporting "unhandled" exceptions /just before/ the application crashes
and burns - one step short of the "A program has encountered a problem"
dialog? Personally, I don't think this is the right place for dealing
with invalid argument values.

Instead what happens is a "First chance ... ArgumentException" is
reported in Visual Studio's Output window

Now that's perfectly /normal/.
All Exceptions are "thrown" twice - you're seeing the first "throw" when
the run-time goes in search of a suitable Exception Handler somewhere up
the execution call stack, collecting Finally blocks along the way. If
it finds one, it then throws the Exception "for real", running all the
finally's it found and then jumping into the exception handler. If you
haven't supplied one, the run-time uses its own - the "A program has
encountered a problem" thing.

but the AppUnhandledException handler is not entered.

If you're seeing the first-chance Exception but it's /not/ popping the
program then it sounds like it /is/ being caught elsewhere.
Have you tried putting a breakpoint in the property and seeing where it
"goes next" when it throws the exception?

If I wrap the call to the User Control's property in a Try Catch block
the ArgumentException is caught. However, I don't want to have to
wrap every call to a property procedure (or group of property
procedures) in a Try Catch block as these seems inefficient.

The whole point of /throwing/ exceptions is that something, somewhere,
has the capacity to /handle/ them, i.e. to do something useful to
"correct" the problem. Otherwise, you might as well just put

End

in your code, wherever a property value is wrong. ;-))
(Really, *really* big grin)

Can someone help me diagnose why my unhandles eception handler is not
working.

It /could/ be a timing issue - if the handler hasn't been "attached" at
the point the Exception is thrown then it won't get called. I don't
know at what point these "handles" clauses get "wired-up".

HTH,
Phill W.

 

[peter_m]

I may be wrong here, but isn't that handler intended for trapping and
reporting "unhandled" exceptions /just before/ the application crashes
and burns - one step short of the "A program has encountered a problem"
dialog?  Personally, I don't think this is the right place for dealing
with invalid argument values.


Now that's perfectly /normal/.
All Exceptions are "thrown" twice - you're seeing the first "throw" when
the run-time goes in search of a suitable Exception Handler somewhere up
the execution call stack, collecting Finally blocks along the way.  If
it finds one, it then throws the Exception "for real", running all the
finally's it found and then jumping into the exception handler.  If you
haven't supplied one, the run-time uses its own - the "A program has
encountered a problem" thing.


If you're seeing the first-chance Exception but it's /not/ popping the
program then it sounds like it /is/ being caught elsewhere.
Have you tried putting a breakpoint in the property and seeing where it
"goes next" when it throws the exception?


The whole point of /throwing/ exceptions is that something, somewhere,
has the capacity to /handle/ them, i.e. to do something useful to
"correct" the problem.  Otherwise, you might as well just put

    End

in your code, wherever a property value is wrong.   ;-))
(Really, *really* big grin)


It /could/ be a timing issue - if the handler hasn't been "attached" at
the point the Exception is thrown then it won't get called.  I don't
know at what point these "handles" clauses get "wired-up".

HTH,
    Phill  W.

Phil

Thanks for your reply.

You asked "Have you tried putting a breakpoint in the property and
seeing where it "goes next" when it throws the exception?"

Yes I have and that's what's got me stumped. The property procedure
throws the following exception:

Throw New ArgumentException("The ACWPeriod is out of range. Valid
range = 0 - 65 seconds", "CTIEngine.ACWPeriod")

When that statement is executed the "First chance exception" message
is printed in the Output window and then nothing further happens. No
further code after the call to the property executes but the
application doesn't "crash". Visual Studio doesn't pop up any dialog
and if you run the application outside of VS nothing meaningful
happens. When you step through the code when the Throw statement is
executed the Next Statement highlighter just goes blank, ie; the code
doesn't go anywhere!

There are no exception handlers higher in the call stack and I
intended the unhandled exception handler to catch the
ArgumentException.

It's almost as if the User Control (which is located in a seperate
Class Library project) from the main project is running in a separate
thread and only that thread dies. However, I've tried adding
Application.ThreadException and
AppDomain.CurrentDomain.UnhandledException handlers but they're not
entered when the ArgumentException is thrown either.

I'm really stumped ...

Peter,