Re: info/CWS slidecopy : ENSURE_OR_CONTINUE/BREAK

On 04/30/10 09:24, Frank Schoenheit, Sun Microsystems Germany wrote:
>> Defensive programming, eh?  Please don't.  (Look up the arguments
>> against it in Bertrand Meyer's OO tome, for example.  "Defensive
>> programming appears [...] to cover up for the lack of a systematic
>> approach by blindly putting in as many checks as possible, furthering
>> the problem of reliability rather than addressing it seriously.")
> 
> Having seen a lot of nasty bugs and crashes which would have been
> prevented by some more defensive programming, I continue to think that
> defensiveness has its justification sometimes. (As always, using your
> brain is a good idea, admittedly.)

Working around errors in the program logic, by continuing in specific 
ways (continue, break, ...) from a point where it is detected that such 
an error manifested itself (assert) may sometimes "happen to work," but 
in the end only masks the latent errors and makes the code unnecessarily 
complex.

("Defensive programming" probably has various connotations.  Note that I 
am not arguing against a programming style that properly takes care of 
all the "unusual" states a program can legitimately get into.  For me, 
that's not "defensive" programming but just plain normal programming.)

If you use those macros not to assert logic errors, but rather to flag 
"unusual program states," I would prefer if you used something more 
appropriate than OSL_ENSURE/OSL_ASSERT for that (say, OSL_TRACE), 
especially in new code.  Remember that 
<http://qa.openoffice.org/issues/show_bug.cgi?id=109142> "Let assertions 
abort" will at one point force use to check all uses of OSL_ASSERT etc. 
to sort out those that assert logic errors vs. those that merely flag 
"unusual program states."

Apart from that, macros that hide control flow are IMO nasty.  Is the 
savings gained by

   ENUSRE_OR_CONTINUE(...)

vs.

   OSL_ENSURE(...);
   continue;

really worth the trouble?

-Stephan