How to get rid of exceptions thrown by the .NET Framework

In a recent project I'm using a lot of databinding and xml-serialization. I'm using C#/VS2008 and have downloaded symbol information for the .NET framework to help me wh开发者_如何学编程en debugging.

The app I'm working on has a global "catch all" exception handler to present a more presentable messages to users if there happens to be any uncaught exceptions being thrown. My problem is when I turn on Exceptions->Thrown to be able to debug exceptions before they are caught by the "catch all". It seems to me that the framework throws a lot of exceptions that are not immediately caught (for example in ReflectPropertyDescriptor) so that the exception I'm actually trying to debug gets lost in the noise. Is there any way to get rid of exceptions caused by the framework but keep the ones from my own code?

Update: after more research and actually trying to get rid of the exceptions that get thrown by the framework (many which turn out to be known issues in the framework, example: XmlSerializer giving FileNotFoundException at constructor) I finally found a solution that works for me, which is turning on "Just my code" in Tools >> Options >> Debugging >> General >> Enable Just My Code in VS2008.

---

You can fine tune which types of exceptions are caught in which way through the Exceptions dialog in VS2008, but If the frame work is throwing "a lot of exceptions" you might want to look into that as well. Just because an exception is handled doesn't mean that it's safe, or that it's not robbing your performance.

---

One way to filter exceptions thrown by the framework is to derive your own exception classes from Exception. You can then use multiple catch blocks:

try
{
//your code here
}
catch (MyAppException myEx)
{
//Do something with your custom exception
}
catch (Exception ex)
{
//Do something (or nothing) with an exception thrown by the Framework
}

---

It might be worth your while to get rid of catch-all exceptions as it is not exactly good programming technique. For an example, if you are working with Input Output such as file reading/writing, trap the IOException instead of the more generic Exception, another example is XmlException for any XML manipulation. Using a catch-all generic Exception may yield a performance hit as the specific exception has to "bubble up" up to the generic Exception Handler.

Hope this helps, Best regards, Tom.