Exception handling

[Harlan Messinger]

Much of what you have here can be both correct or incorrect depending on
platform and/or language.

FWIW, this was FORTRAN 66. We didn't have explicit if-blocks yet, only
computed GOTOs!

Exceptional versus nominal first:

If you are dealing with input validation (what code contracts is
supposed to aid with in .NET 4.0), you would code exception first, as
you might as well throw out items that will not make it through the
routine. This is more efficient, especially in "traffic cop" type of
routines (of course, inversion of control can eliminate some of this
argument). There are probably other reasons to have exception first, but
this is a primary case. Once again, the code contracts may eliminate the
need to explicitly code some of this.

Outside of these types of cases, i would aim for nominal first, but I
also subscribe to a TDD approach to development, so solving the problem
with as few lines of code as possible is the first step.

Single Point of Return:

The reason for the "rule" is discipline. If you try to adhere to the
rule first, you find that you generally end up with better code. The
reason is you do not end up taking sloppy short cuts (aka, kludges) to
get through the routine.

It took a lot of discipline, but I found it led to lots of sloppy code,
where I kept testing the same cases over and over again at each section
of the routine. Given nested IF-blocks, the corresponding result would
have been unfathomable nesting.

I also find enumerating each of the exception cases and then letting the
nominal case be the "else" case much more intuitive than having the
nominal case first. If possible exception conditions are booleans E1,
E2, and E3, I think

if (E1) { ... }
else if (E2) { ... }
else if (E3) { ... }
else { ... }

to make a lot more sense than

if (!E1 && !E2 && !E3) { ... }
else if (E1) { ... }
else if (E2) { ... }
else { ... }

where whichever condition is arbitrarily selected to be the "last" one
doesn't even get explicitly stated , which I think is poor practice, or
else the final condition can be written as

else if (E3) { ... }

but even though one can tell by looking at ALL the conditions that all
possible conditions have been exhausted, *formally* it looks like I'm
ignoring the potential default case. I don't like not ending with a
naked "else" when the if-structure is meant to handle all possible
cases, because it makes it look as though I might not be, and forces the
person reading the code to logically "or" all the conditions together to
determine that I've actually covered all possible cases.

Finally, the contingent code for the exceptional cases tends to be
shorter--"let's wrap this up and get out of here"--than the nominal
case, which often goes on to do more processing, and I think it makes it
easier to get the feel for the if-structure as a whole if the shorter
cases are gathered at the top, as opposed to a situation where the
original if-block is very long and even the first else-block is a couple
of screens down.

As with all "rules", there are instances where you have to break it.
But, if you adhere first to the rule and then break when needed, you
find you have better code.

Professors are there to drill in the basics. over your college career,
you generally find the classes more rigid at first and less as you get
to upper level courses. If you had an upper level professor that
subscribed to ALWAYS, you probably were dealing with an ideologue.

Regardless, if they don't initially teach things as rules, you do not
take the ideas seriously.

Understood.