[Cfp-interest] exceptional macro

[David Hough CFP]

> A "test" function (or macro)
should not have side effects, because if it does it compounds a problem rather
than being a means to a solution


Let's recall the common case here:

 Do the usual thing.
 If the unusual thing I'm worried about arises, do something different.
 If the unusual thing I'm worried about does not arise, continue.

In other words, what's computed in the usual thing should be ready to
continue if the unusual thing does not arise.

To me that means that there should be no difference between

 compound-statement ; exceps=0 ;

and

 exceps=FP_EXCEPTIONAL(compound-statement, excep1, excep2, ...);

in the common case that none of excep1, excep2, etc arise.

All the side effects should occur the same, including all the exceptions
that are not named.     The named exceptions, which are the ones the
programmer is worried about, do not raise flags or cause traps because
they are indicated in the macro value.

Likewise we wouldn't want any more performance penalty than necessary
for these two ways of expressing the common case.     That performance
penalty is not avoidable completely - the compiler might 
 check operands/results,
or 
 check flags, 
or 
 enable traps,
depending on the implementation characteristics -
but you don't want the performance penalty
to be any worse than what the programmer would
suffer if he did it all explicitly himself.

And so that's why I think the interesting exceptions should be named
explicitly, so they can be handled differently from the uninteresting
exceptions that might or might not arise as well.