Steve Sheldon

Which exceptions should I be catching when calling a method in C#

I normally write blogs about travelling all over the place in an RV but today I felt like writing about one of my other passions – writing software. In particular I have chosen to write about something that I have always found annoying and never really had a good solution for.

Most of the time professionally I am called upon to write code in C#. I like writing code in C# but there’s one facet to the language that I have some frustration with. I often find myself having to write code like this:

int someValue;
try
{
    someValue = someClass.UseSomeCodeWithNoDocumentation();
}
catch (Exception)
{
    // Bad Bad Bad to catch a general exception like this.
}

Catching generic high level exceptions like this is bad practice because it can hide a plethora of failures that should percolate to the top. For example, running out of memory is probably a good time to shut down, no good is going to come to a users project if you try to continue with no memory to work with.

Having said that,  customers generally tend to get upset when their applications crash so it’s best to avoid that as much as possible. It makes no sense to have the companies reputation dragged through the mud because we forgot to handle some exception that didn’t really matter anyway. I was googling around today looking for a better way to handle this kind of situation and most answers boiled down to answers that only really work in an ideal world. The basic consensus was:

  • Only handle exceptions you care about.
  • Always check the doc’s as they should always tell you what to check for.

It’s the second point I have contention with, it screams of the kind of idealism I seldom see in the production world. Documentation can’t be trusted a lot of the time, even for companies who’s product happens to be a software API. Furthermore, what about internal code on a product where not every method has an auto comment block?

I did find one article that tried to be more pragmatic here:

How can I determine which exceptions can be thrown by a given method?

In this article, one of the developers answering has a nice code sample which makes us of a library called “ILReader” to programatically figure out which exceptions can be thrown. Now I will say now that none of this is a perfect science. But in the name of due diligence, I think anything is better than nothing so bravo to these guys for coming up with a pragmatic way for the rest of us who ship real software to have a way to check which exceptions a method will throw.

The next step for me was that I would like a way to be able to:

  • Load an assembly
  • See a list of namespaces, classes and methods
  • Select a method
  • See the exceptions it throws
Something like this:
 

I figured I am not alone in wanting something like this so I wrote it.

Some caveats:

  • It can take a minute to run, I haven’t gotten around to progress bars yet but will add that in the future unless somebody beats me to it.
  • It’s going to skip generic types
  • There’s always the chance some weird dependency won’t be loaded by the .net dependency walker – if you hit this try moving your app to the same directory as the assembly you want information about.

If you can live with some of those limitations (or if you can’t but feel like updating my code), you can get a head start on this problem in the future by checking out the tool I wrote. You can download the source from GitHub here:

C# Method Exception Reflector

Feel free to fork my depot or put in pull requests for any features you think this tool should have. Some at the top of the list would be:

  • Search
  • Progress
  • More robust assembly loading and graceful degradation when not possible

 

Happy Travels,

Steve