Re: [ADVANCED-DOTNET] Exceptions and the WinForms Paint event
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.
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
-Original Message-
From: Ivan Towlson [mailto:ivan.towlson;WHITE-CARBON.COM]
Sent: Monday, October 21, 2002 8:16 AM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Exceptions and the WinForms Paint event
[I had no joy with this on the Windows Forms list last week, so would
like
to put it to the advanced list. Apologies to those who have already
seen
it.]
If I have an unhandled exception in a normal event handler, such as a
button click, the debugger drops me in at the exception site. E.g.
private void button1_Click(...) {
int naughty = 2;
int bang = 10/(naughty-2); // debugger highlights this line
}
But if I have an unhandled exception in the Paint event, the debugger
drops
me on the Application.Run statement. E.g.
static void Main() {
Application.Run(new Form1());
} // debugger highlights this line
private void panel1_Paint(...) {
int naughty = 2;
int bang = 10/(naughty-2); // but I want to be here!
}
The call stack is all Windows Forms methods (apart from my Main):
there's no
sign of my Paint handler in the call stack.
Do other people see this behaviour?
Can anyone explain why it happens? (The call stack bottoms out in a
method
called PaintWithErrorHandling: I guess this is throwing a new exception
instead of just rethrowing mine. But why would it do that?)
And on a more practical note, are there any good ways to persuade the
debugger to catch Paint-related exceptions at their site?
--
Ivan Towlson
White Carbon
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
