views:

152

answers:

1

I'm debugging a WinForms client that calls a WCF service in VS2010 Beta 2.

I want to test my exception handling code, so I intentionally mis-configured my endpoint in app.config. The expected ConfigurationErrorsException is thrown. However, VS2010 stops on the offending line of code even though I have set it not to break for either Thrown or User-unhandled exceptions.

If I try to start without debugging, I get a generic "My Program has stopped working" dialog with the option to debug. If I elect to debug, it brings me back to the same line where the exception was caught.

The line that I can't get past is:

MySvc.MyServiceClient svc = new MySvc.MyServiceClient();

If I instead simulate an error by doing division by zero somewhere in the client (or just plain throw an Exception), the debugger behaves as I would expect and enters my error handling code.

My take away is that I cannot actually handle the exception when app.config is misconfigured. Am I missing something here?

UPDATE:

I am handling the Application ThreadException event to try and catch this:

Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
+1  A: 

Ctrl+D, E should allow you to configure VS exception handling options. Uncheck "Common Language Runtime Exceptions" and then your code will handle all exceptions.

EDIT (by poster)

The comment provides the correct solution.

Perhaps the exception is happening on another thread somehow via an asynchronous call in the WCF proxy? Try hooking the Application.UnhandledException and AppDomain.CurrentDomain.UnhandledException events and see if they catch your culprit.

Jesse C. Slicer
I already did that "even though I have set it not to break for either Thrown or User-unhandled exceptions"
Eric J.
Perhaps the exception is happening on another thread somehow via an asynchronous call in the WCF proxy? Try hooking the Application.UnhandledException and AppDomain.CurrentDomain.UnhandledException events and see if they catch your culprit.
Jesse C. Slicer
That did it! Interestingly the MSDN UnhandledExceptionEventArgs entry http://msdn.microsoft.com/en-us/library/system.unhandledexceptioneventargs.exceptionobject.aspx is utterly useless, but someone pointed back to SO in the community comments for a great explanation.
Eric J.