Unhandled exception

[davidsimmonds]

I have a Windows Forms application. It loads assemblies with the extension .Plugin.dll with Assembly.LoadFi le. One of these "plugins" calls into another assembly dll. That dll eventually throws a ValidationExcep tion exception. The method that throws the exception is in a class that inherits from IDataErrorInfo. This class is a class that is contained in a Linq to SQL class (.dbml). In the "plugin" I call DataContext.Sub mitChanges. This is wrapped in a try/catch block. This causes my business logic to validate the data before submitting to the database in the OnValidate override. The result that I see is that after the ValidationExept ion is thrown, the debugger stops at the bottom of the OnValidate method indicating that an unhandled exception has occured. If I continue to run the app my catch block is executed. That is what I wanted in the first place, but why am i getting an unhandled exception when it truly is handled?

[Falkeli]

I'm not sure, but this may be a feature of the debugger, designed to help you debug the program if an unexpcected exception occurs under these circumstances.

[davidsimmonds]

If anyone else is sure about the answer it would be helpful. I get other exceptions thrown and I handle them and the debugger does not stop. Why does ValidationExcep tion stop.

[GaryTexmo]

I too have noticed this behaviour... I just can't quite recall the circumstances. I feel like it was situation where threading was involved... like, I'm catching an exception in another thread and then reporting it back to the main thread. It was a while back so I can't remember the exact situation but like you, I couldn't make the debugger ignore it.

It is quite annoying though, but it's only when debugging. Your program will execute just fine when you run it normally. As Falkeli said, it may well be a "feature". If you figure out a way to disable it, please share!

[davidsimmonds]

Yeah, it is likely a thread issue since the exception is thrown in my DAL component and that component is running the database. So the database could have done something asynchronously, thus a different thread, when it threw the exception.

Nice feature. Not.