Programmer Musings

The Nature of Exceptions

While I was at YAPC::NA this year, I got a chance to catch up with a few old friends and talk with some really knowledgeable people from other parts of the Perl community. One such discussion started when Rob Kinyon told me that "exceptions are fundamentally flawed by design and should never be used." (I'm paraphrasing here. I didn't take notes on his exact words.)

I've used exceptions in multiple languages in the past decade. I've seen both good and bad usages of exceptions. I've also heard many of the arguments against exceptions over the years. (I actually touched on these years ago in the post Joel on Exceptions.) I asked if he could explain, mostly so I could hear which arguments he would use. I really expected the same old arguments. I was quite pleasantly surprised when Rob made some really interesting points in a direction I had not heard before.

If I understood him correctly, there were two major points to his argument.

• Exceptions thrown by functions down the call stack and caught later introduces coupling between widely separated pieces of code.
• The exception object is not part of the parameters or return of any of the functions, so it acts somewhat like a global variable, which is bad.

These arguments were not like the normal complaints I've heard about exceptions. Rob's arguments were actually fairly well-thought-out and well-argued. During the discussion, we ended up attracting Piers Cawley into the discussion. The discussion turned pretty lively after that.

Coupling

I don't think I presented my thoughts very well in that discussion. So, here goes. Let's start with the coupling argument. The simple example of Rob's argument looks something like this (in pseudo-code).

   sub foo {

       ...

       bar();

       ...

   }

   sub bar {

       ...

       baz();

       ...   

   }

   sub baz {

       ...

       if( bad_stuff ) throw bad( "Shouldn't do this." );

       ...   

   }

Rob suggested that foo() is now coupled to baz() because it needs to be aware that a bad exception may be thrown. This would obviously be bad, because baz() is an implementation detail of bar() and foo() should only know about bar().

In fact, foo() is not coupled to baz() at all. Calling baz() has just expanded the interface of bar() to include the ability to throw a bad exception. In fact, that is no different than if the implementation of bar() were changed to throw a bad exception. This is really no different than having to change the calling signature of bar() to add a new parameter needed by baz(). The foo() function does not need to know what bar() does with the parameter (or exception), just that it is part of bar()'s interface.

What this argument does point out, however, is that the exceptions that may be thrown by a function are a hidden portion of the interface. Now, I'm sure some Java-fans will be getting smug about Java's checked exception system. Using this facility, the programmer must specify all of the exceptions that may be thrown by a method. Unfortunately, it's been my experience that system breaks down in maintenance as changes in lower-level code necessitate touching arbitrary amounts of calling code to fix up the throws clauses to deal with new exceptions.

It seems that many programmers eventually either change to unchecked exceptions or declare that all methods can throw an Exception or Throwable, so that anything is allowed. Better design skills or an architecture that converts exceptions to more generic forms as they move between layers can mitigate this issue. But, it does point out an implementation issue with exceptions. Exceptions seem to either result in a hidden interface or a lot of extra maintenance. Perhaps later implementations or better architectures will remove this issue.

Exceptions as Globals

The other argument that Rob made was that exceptions are basically global objects. Like globals, when you access the exception object you have little idea where in the code it was generated. Possibly the biggest problem with a real global is that it may be changed by literally any piece of code in the system. The only way to find out where the global is modified is to examine every piece of code in the system.

Rob's argument was that it is possible that you would need to examine a large amount of code to determine the context for the thrown exception, since the exception might have been thrown from a point far from where we catch it. Unlike a real global, exceptions are only created in code called by the point where we catch the exception. So, in theory, this limits the amount of code that would need to be examined. In some cases, however, this limited amount of code could still be a large section of the codebase.

Java exceptions reduce the effects of this issue to some extent by providing a stack dump in the exception. Depending on the system, that might be almost as bad as searching the code. Other systems support a method of chaining exceptions. In these kinds of systems, you catch an exception when you have more context to add and throw a new exception containing the old exception and further context information. Done correctly, this can reduce the noise of a stack dump type exception and increase the real, useful context available to deal with an exception.

The Meaning of an Exception

One of Rob's arguments was exceptions are not actually necessary. He argued that when something goes wrong in code, there are basically two possible ways of handling the problem.

1. Automatically recover the error condition near the point of the problem.
2. Code gives up and hands control to a human to handle it.

Piers made the very useful observation that exceptions give us another recovery method in between those. This allows the code to basically say I've got a problem I can't handle, someone handle this for me. If no code handles the exception, it basically degenerates to the second case. But, if higher-level code has more context and can actually handle an issue that the low-level code can not handle, an exception allows the code to turn the second case into the first.

So an exception can actually be looked as a a call for help from the lower-level code for someone else to deal with a problem.

Conclusion

To me, at least, Rob's arguments were interesting, but not compelling reasons to avoid exceptions. They also weren't strong enough to justify the claim that th design of exceptions are fundamentally and fatally flawed. I would also agree that certain implementations are less than ideal and that the best exception implementations only exist in the future.

Programming for/by Kids: a Followup

At the beginning of last year, I wrote Programming for/by Kids talking about my experience getting my young son programming using the Scratch language. Shortly after I wrote that piece, he lost interest and stopped. As usual, something else caught his attention and he was off working on that. When I noticed that he wasn't talking about wanting to program any more, I figured that he had worn out his desire to program and that would be it. I was a little disappointed, but he has his own interests.

Fast forward a little over a year and he is assigned a project in school to do a report on a book. From what he says, the teacher has suggested that the kids do PowerPoint presentations for their reports. (Fifth-graders doing PowerPoint, the world is changing...) My son decides that he wants to do something a bit more entertaining than a basic slide presentation. So, he fires up the Scratch environment and starts building a little movie for his report. He asked for a little help on a few things, but mostly works at it steadily for several days on his own.

As the project nears completion, we discussed the problem that his teacher might not be willing (or able) to install the Scratch environment to run his movie. With a moment's thought, he decides to get his digital camera and record a video of the movie playing on his screen. He put both the Scratch program and the video on a thumb drive and brought them to school. His report was a success.
Even though I had thought he lost all interest in programming, he had actually learned what he wanted and kept those skills for later use. Unlike this old programmer, he was interested in programming for the end product and not the process.

If any of you out there decide to try to teach programming to kids, you might want to watch for a completely different mindset than we had when we were learning. Given that computers are everywhere in kids lives today (their phones have more power than the first computers I programmed), they probably see programming very differently than we do.

SVG Lives: A Follow-up

At the end of 2008, I did a series of posts arguing that SVG still lives despite predictions of it's downfall. I had been hearing these dire predictions for years, and wanted to provide a decent rebuttal: Reports of SVG's death exaggerated.

Last year, I had the good fortune to go to SVG Open 2009. Despite following SVG for years and working with it where ever I could, I was still astounded at the creativity and power of the technology shown by many of the experts that were at the conference.

This year I had the opportunity to present at YAPC::NA on the topic Data Visualization with Perl and SVG. I expected a handful of attendees, and was surprised to be presenting to a packed room containing over 50 people. Apparently, there is quite a bit of interest in SVG.

There have also been a couple of changes in the world of SVG lately that should finally lay to rest the claims of SVG's demise.

* HTML 5 will include SVG support in-line with the HTML.
* IE 9 will finally begin supporting SVG natively.

As with many technologies, it looks like SVG has survived its first ten years and is about ready to break out into the mainstream.

Open Source and Volunteer Organizations

I just got back from YAPC::NA 2010. As usual, the presentations were great and the people were better.

At last year's YAPC, I had the good fortune to attend a talk by Karen Pauley entitled Remote Controlled Volunteers. It's not the kind of talk I would normally look for, but I thought I would check it out anyway.

Boy, was I glad I did. Karen (currently The Perl Foundation president) has a lot of experience dealing with volunteers. Her observations of the connections between the open source community and difference kinds of volunteer organizations were right on target. Since my wife does a lot of work with volunteer organizations, I wanted to show her Karen's slides. I was never able to find them.

When I got a chance to talk to Karen at this year's YAPC::NA, I told her (again) how much I had enjoyed the previous talk and how disappointed I was that I had never been able to show it to others. Fortunately, she had polished the talk some more and presented it again. The paper Understanding Volunteers is the essence of the talk I was looking for, and she gave me the link.

If you ever have a need to understand what drives a particular open source or volunteer group, this paper is a real help. Open source projects are as much (or more) about the people as about the technologies. Many of us technologists forget that. Karen obviously doesn't.