lessonOfTheWeek == !onesize.fits(all)

| 3 Comments
I've enjoyed the hoo har over exceptions this week. It's made me think and analyse and reassess what I do. I'll be continuing pretty much as before, but it's worth spending the time to think about these things once in a while.

It was interesting to see people defending their positions and how some were open to new and different ideas and how some were not. It was useful to be reminded that what I consider an acceptable development trade-off may be completely different to what someone working on embedded stuff thinks is acceptable.

All good stuff that keeps the brain working and for me I think this was the best observation from on the whole thing.

From Joel's discussion forum; Ged Byrne defends Joel's position and reminds us all that one size doesn't fit all:

Not very long ago Joel's preferred method, using method returns to indicate error, was industry standard.

The whole Windows API reflects this method. In the Win32 programming the Boolean return even has 3 states, with one to indicate errors (Troolean, perhaps [1]):

Joel is from this environment. He has worked with this style for years, and has become very good at using it. He developed from intern to leader in the field using this style.

Refactoring puts a lot of emphasis on Code Smells [2]. The name of it tells use that we are dealing with something intuitive rather than something logical. An experienced programmer knows when code is going bad, his code note can smell the decay and it can become unbearable.

For experienced C programmers, code that looks like this:

{
    DoSomething();
    DoSomethingElse();
}

Stinks like rotten eggs. He looks at it and says where's the error handler. Whats going to happen in this case, or that case.

Sure, exceptions allow you to handle all those exceptions in a cleaner manner, but that doesn't matter. The code nose was trained elsewhere and will never learn to tolerate that stench.

Many fine arguments can be made for exceptions, and I buy every one. I love exceptions, because to me the above code smells like a vally of roses.

Are these arguments persuasive enough that Joel should ignore the smell and change over to using exceptions?

Certainly not, because the real benefits of Exceptions are minor. Would Citydesk or Fogbugz have been significantly better products if exceptions had been used? No.

Would they have been developed quicker using exceptions? No.

In fact they would have been developed more slowly, because the benefits of using exceptions doesn't even come close to the benefits of a well trained code nose refined over the years.

[1] http://www.relisoft.com/win32/winnie.html
[2] http://c2.com/cgi/wiki?WhatIsaSmell

Ged Byrne
Thursday, October 16, 2003

So, Joel; what's your position on code comments? ;)

3 Comments

I just think that in C++

try
{
DoSomething();
DoSomethingElse();
}
catch(Ex &e)
{


}

is much easier to maintain and read than

{
ret_code = OK;
if (!DoSomething())
{

ret_code = ERR;
}
else if (!DoSomethingElse())
{

ret_code = ERR;
}
return ret_code;
}

since the normal flow of the code (which lets face it in most programs is 99% of the time where it goes) is obscured by all the error handling.

I have to admit though I do write in both styles and often in a combination of both due to 3rd party libraries working in the second form (Summit Len...). When I wrap them though I change all the return codes to exceptions.
;-)

Hey - my code got all messed up and my comments in > and < got removed - tut tut are these comments just getting output in plain old text straight into HTML or XML?

I think it does some processing of comments before storing them, cant remember how it works.

Agree re the exceptions and the wrapping :) Did you ever see the instances of 'exceptions used as a clever local goto' in the Summit source (when we had the source license at CSFB)? There are some of those 1000+ line functions that use exceptions and throw and catch the exceptions within the same function to transfer control and then return error codes...

Leave a comment