Thanks Mike. Unfortunately, while I'm aware of the ability to break as soon
as the exception is thrown, it's not usually a good thing, which is why it's
off by default. The problem is that the program halts even on handled,
expected exceptions. Consider the following Paint code:
try {
g.DrawString( NaughtyFunc().ToString(), ... );
}
catch (DivideByZeroException) {
g.DrawString( "Error!", ... );
}
g.DrawString( SeductiveFunc().ToString(), ... );
Here it's perfectly okay for NaughtyFunc to throw a DivideByZeroException: I
know it can happen and I'm perfectly happy to handle it. I don't want to
break into the debugger when this happens -- particularly because this is a
Paint cycle, so breaking into the debugger will push VS.NET to the front, so
when I hit Continue, the app will have to repaint again, so it will break
again...
But I'm *not* expecting an exception from SeductiveFunc, so I *do* need to
break at the exception site if one occurs -- not to be dumped on
Application.Run with no hint as to where the Paint code blew up.
Of course if I know that the WinForms-eaten exception is of type X and that
my code doesn't use exceptions of type X anywhere else, then this is an
acceptable workaround. However, I've had to try this in Delphi (which
doesn't distinguish handled and unhandled exceptions and therefore forces
you to break on all exceptions of the type, even handled ones), and
unfortunately I find it's all too rarely the case!
Thanks for your help,
--
Ivan Towlson
White Carbon
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@;DISCUSS.DEVELOP.COM]On Behalf Of Xwscom1
Sent: 21 October 2002 19:49
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Exceptions and the WinForms Paint event
Ivan, If you are using VS7, you can go to Debug|Exceptions to bring up
the Exceptions dialog, click on the 'Common Language Runtime Exceptions'
Item in the list and down in the control groups at the bottom select
When the Exception is throw: Break in the debugger radio button. Hit OK
then start debugging. You'll now break in the debugger at the place
where the exception is thrown.
I suspect that you are winding up in your own code when the exception is
thrown because that's the first place on the stack that symbols were
loaded for.
Mike
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
