Exceptions Part 5: The Myth of the Exception Hierarchy

See the Contents Page for this series of articles

Last time we identified a serious oversight in the JVM’s exception model (that the runtime unconditionally executes finally blocks before first figuring out whether active exception is even going to be caught), so we’ve made Java look bad. Now let’s heap some abuse on object orientation itself.

Exceptions Part 4: What happens if ‘finally’ blocks always execute?

See the Contents Page for this series of articles

It’s a widespread belief that finally blocks “always” execute, sometimes with hilarious implications.

Last time I reasoned logically that in order for our code to have predictable behaviour, we should stop it running when it becomes clear we don’t understand the state the program is in. As finally blocks are filled with little chunks of our code, it stands to reason that they shouldn’t execute when things get Ugly.

Now I’m going to discuss the specifics of what can go wrong if they are always forced to execute, as they are in a couple of popular languages, C++ and Java (and also by default in CLR-based languages).

Yes, this is a long one, but I’m going to try to start a few language wars, so it should be fun!

Exceptions Part 3: Why do we need ‘finally’ blocks?

See the Contents Page for this series of articles

C# programs compile to an intermediate language (IL). If you want to dig deeper into exception handling, IL doesn’t seem very enlightening at first, because it also has the keywords try and catch. It’s like opening a TV and inside it… there’s a little TV. That’s no kind of explanation!

Exceptions Part 2: Why do we need to catch them?

See the Contents Page for this series of articles

Last time we established that an exception is the way a function unambiguously produces no value – or no side-effect, which amounts to the same (no)thing. To take the best known example from mathematics, the function f(x) = 1/x has no value if x is zero. If you’re asking what anything divided by zero is, well… you shouldn’t be asking. Just don’t ask.

But by catching an exception, you are saying “I expect this”. So to be entirely rigorous about it, isn’t it wrong that we ever try to catch these things? Maybe, like in mathematics, we should never attempt to evaluate them in the first place.

Exceptions Part 1: What is the Purpose of Exceptions?

A few months ago I wrote some long comments on an Eric Lippert blog post and ever since I’ve been meaning to distill them into something more coherent.

But I can’t! If anything my rambling notes get longer and longer. Exceptions simply aren’t that simple. Of the four big commercial development languages (C++, Java, VB.NET, C#) there are similar keywords for exceptions but significant differences in how they work. Then there are the “lightweight” platforms, JavaScript in the browser and Objective-C on Apple’s iOS, which again have the same keywords but not the same attitude to when exceptions should be used.

Fatal Exceptions, and Why VB.NET Has a Purpose!

Updated 2010-06-22: I’ve modified the conclusion of this post slightly – all the same information is there but I’m less forthright in my demand that C# be extended to match the capabilities of VB.NET. The reasons why I’ve changed my mind on this are long and complex so I’ll address them in a series of articles about exceptions in the near future.

Updated 2014-12-15: Exception filters are being added to C# 6, which should be out next year. Amazing what can happen in just 6 years! 😛

There’s a feature in the CLR that is exposed in VB.NET and not in C#. Apparently this is a deliberate decision made by the C# team, which so far they’ve stuck to. Unfortunately, it’s a pretty important feature.