2

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 when 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.

Community
  • 1
  • 1
Hans Løken
  • 407
  • 1
  • 6
  • 15
  • 3
    Write good code usually works. – R. Martinho Fernandes Nov 24 '09 at 15:21
  • Hey, that's a really constructive reply. I'll start doing that then. I am not sure you understand the problem. These are exceptions that you would never see unless you : (1) download debug symbols for the framework, (B) run in the debugger, (C) turn on Exceptions->Common Language Runtime Exceptions->Thrown. They seem to happend a lot in regards to databinding, especially inside the datagrid. – Hans Løken Nov 25 '09 at 08:39
  • 4
    @Hans: Don't take it personally. I agree with you that a comment like that is not constructive and does not show a lot of insight. I am amazed that it got two upvotes. – heijp06 Nov 25 '09 at 11:58
  • @Peter: Thank you for the support, I shouldn't really have reacted to that kind of comment but I'm surprised by the upvotes myself. – Hans Løken Nov 25 '09 at 12:34

3 Answers3

6

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.

David Hay
  • 3,027
  • 2
  • 27
  • 29
2

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
}
Dave Swersky
  • 34,502
  • 9
  • 78
  • 118
1

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.

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
  • That's a good idea! Temporarily disabling it will at least let me debug the exception when it happens. Thank you. – Hans Løken Nov 25 '09 at 08:42