What’s wrong with this code redux…

Thanks to all for their comments on “what’s wrong with this code”.

I will confess to making a tactical error in presenting the code. I started only showing a single error, and then I went back and showed another one.

Ones that people commented on:

Not checking for InnerException to be null

I didn’t intend this one, so +1 for my readers

Datastore not getting tested in the use

I hadn’t intend this to be a full, usable class, so there’s other code not shown that makes this a non-error.

Error in constructor

This was the error that I added, which just confused this issue. Whidbey may catch this one – I’m not sure.

Not rethrowing in the catch

This was the error I was intending to highlight. The code I wrote swallows all errors that weren’t of the proper type.

There are really two issues with this code. The first is the more obvious one – the fact that I’m dealing with one type of exception, and not rethrowing all the other types.

The more subtle issue is that the api that I’m calling is flawed. APIs should never force their users to have to depend on the inner exception for everything. If you find your users writing code like that, you haven’t given them enough richness in the set of exceptions that you throw.


Comments (3)

  1. Hi Eric,

    So try/catch/finally.

    Finally is a construct that is required by managed code because unlike C++, C# is garabage collected and so instead of your instances going out of scope and being destructed, you are now in the non-deterministic state of waiting for collection.

    Cool.. Nothing better!

  2. Diego Mijelshon says:

    Sometimes, handling the InnerException is the only way to do stuff… consider this case:



    method.Invoke(obj, args);


    catch (TargetInvocationException ex)


    if (ex.InnerException is MyExceptionType)


    //handle it







  3. Hugo Rodger-Brown says:

    Is it possible to get hold of the slides for this talk – I’d love to see the samples?