Jeroen’s weblog

VB has an exception handling trick up its sleeve that C# doesn’t: the when-clause, an optional part of a catch-statement. At first I thought this was a great feature and wondered whether C# would get it in a future version, but the more I think about it, the more I’m convinced that C# won’t get the feature. In fact, I personally think it shouldn’t get the feature and don’t think I’ll ever miss it in C#.

Not that there’s anything particularly bad about it in a typical scenario: when writing custom front-ends, you tend to have to handle specific errors that are related to the implementation of subsystems that the current solution uses. For instance when writing a front-end for a client that uses a specific database, you might expect some exceptions to be thrown that won’t occur when coupling a front-end to another database or storage component.

But that’s where it stops. When you look into other cases, such as frameworks or class libraries, catching exceptions based on some external factor or some aspect of the exception itself (a popular use for the when-clause is to check for the type of the InnerException) becomes questionable. If an exception occurs and you want clients to be prepared to deal with them, you should always propagate them consistently.

If you don’t, client applications are bound to show up that don’t deal with the exceptions at all, perhaps because during development, the external factor that causes you to choose to handle them in the when-clause is always true. And then at deployment, some lower component’s implementation is replaced and suddenly InnerExceptions start popping up that your when-clause doesn’t catch, so you suddenly start throwing exceptions to a client that doesn’t expect them.