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.

Idempotent

I’m reading a Java standard right now and it contains a very common mistake:

Render URLs should not be used for tasks that are not idempotent, i.e. that change state… they should not change any state on the server. As a consequence, render URLs may become
bookmarkable.

That’s not what idempotent means. It’s just what a lot of people seem to think it means.

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!