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.