Exceptional programming is pessimistic programming

Posted Thursday, May 12, 2005 11:48 PM by andy

Edited after Cyrus' comment on the using statement. My point was that dealing with these cases correctly is difficult to a degree that the language and platform developers can get tripped up by this stuff.

I’m a fan of Joel Spolsky and he just posted an article on a couple of subjects, Hungarian notation and exceptions. 

Making Wrong Code Look Wrong

It is one of the best descriptions of the good and bad points of Hungarian notation that I have read.  I’ve never used full Systems level Hungarian notation, but I used the heck out of a basic form of it whenever I had to program in VBScript since there wasn’t any other way to tell what type you had at any given time.

I’m in violent agreement with the point of the article, and it is a specific case of a general principle.  Always make it easier to do the right thing.  This is the goal every process should strive to reach.  It doesn’t matter if it is the mise en place principle in cooking, or making sure that all your tools are easy to find and entice you to put them back in the right place, things will always go better if you have as many things that you need in front of you, and the absolute minimum to get in the way.

There are some things I disagree with in Joel’s article.  Exceptions being one of them.  The thing that I really like about exceptions is that they make it easy to do the right thing.  An exception is for when something has gone really wrong and the right thing to do is to drop everything else and fix it right now, or just drop everything and let it all go to hell.  Return values just don’t do that.  It’s easier to ignore them completely and let data get all messed up (I would say corrupted, but I can’t stand the phrase corruped data anymore), and that is what regularly happened in many older applications, which is why exceptions have become so popular these days.

Exceptions have one other property that I think is driving Joel’s dislike for them.  You can’t just use them a little.  Exceptions force you to code like every function and every statement can throw an exception period.  Adopting exceptions is like moving over to multi-threaded programming, you have to distrust everything all the time.  You even have to worry if something throws between creating a new object and assigning it to a variable, and even the current C# using statement can leave things open for potential leaks.  The assignment statement can be just as tricky with double locking in thread safe code.  You have to worry about the compiler optimising pointer copies.  Things sure are more complicated then when you could just write some C code, check some return values and keep on going.  Now, even though your app might be a simple single threaded application running in it’s own safe little memory space, it’s running on a multi-threaded operating system dealing with virtual memory, and cuddling up to 12 other applications think they are safe running in their own little world. 

To paraphrase Joel, this is going to be one heck of a leaky abstraction.  Even though you don’t use exceptions or threads in your application, all the complexity of the operating system is going to leak in and remind you of it in some pretty nasty ways.  Even though you don’t use C++ exceptions, windows has it’s own form of exceptions, and every memory access can potentially generate these.  So even if you want to avoid exceptions and threads, these days you just can’t. 

Joel mentions a few levels of development knowledge in his article, from a complete novice, to someone that recognises code formatting issues, to someone that cares about things like making wrong code look wrong.  I think there is another area, someone that has seen enough things go wrong, in there code that a pessimistic view like exception handling looks good.  While I haven’t seen errors like xor eax,eax fail, I have seen many many strange things happen to my code.  For 5 years I worked on Dell’s support site.  While I worked there it would routinely get around a million plus page requests a day, so at least one once in a million events happened in our code a day.  In fact I think the best day error wise we had while I was there was somewhere in the thousands.  That’s pretty incredible for VBScript and a whole mess of nested include files.

So, are exceptions the best thing to squeeze their way between a couple of curly braces?  I wouldn’t say that, but they make things better in the worst case, and when you have to deal with the worst case every day, that is a very good thing.

Filed under:

Comments

# re: Exceptional programming is pessimistic programming

Thursday, May 12, 2005 10:18 PM by andy

Wow. I couldn't disagree more with Joel.

He's right in that Hungarian got twisted into encoding types into variables, and that's an abomination. However, he's wrong in the need for names to encode domain specific information in order to prvent mistakes and to help developers identify mistake through simple visual inspection.

He mentions the case of unsafe and safe strings, but fails to recognize a far better solution.

Have two types:

UnsafeString and SafeString,

and only allow Write to take a SafeString.

Now your type system will prevent such mistakes from happening and you will *never* have to inspect your code to make sure it's doing the right thing. If it wasn't doing the right thing it wouldn't compile!

Joel encourages the developer doing something which the *compiler* can do infinitely better.

---

And, the C# using doesn't get things wrong. The problems i mentioned are still a problem even with return codes. An asynchronous error is going to be difficult always. (unless you somehow make sure that all execution paths are properly protected to behave atomically when needed).

# re: Exceptional programming is pessimistic programming

Thursday, May 12, 2005 10:43 PM by andy

Wow, I never thought I'd get a response out of this.

Sorry about the comment about C# doing things wrong. That was too strong a statement. The point I was trying to make is that there are oportunites for exceptions lurking behind even the most innocent looking statement. Programming with return codes doesn't protect your code from that, neither does using exceptions, but since you always have to deal with exceptions at some level, it makes sense to treat them all the same way.

# re: Exceptional programming is pessimistic programming

Thursday, May 12, 2005 11:11 PM by andy

You'd be surprised who you get read by :)

I know i always am.