Markus, of course, i agree that defensive programming is a must at least in critical places, and no i do not like the idea to have my data corrupted. In fact, defensive programming at low level is a prerequisite for doing optimistic programming at higher level.
 
 Once you have put these exceptions at critical low levels, it is in some cases (i do not say all cases) far more comfortable to squeeze higher level precondition/postcondition tests and use exception handling instead. This is where i am speaking of programming style.

Lost of performance come not only from low level defense, but also from testing several times the same assertion in the call chain. Removing second half is not risky.

Nicolas

Markus Gaelli:
 
 On Mar 17, 2006, at 3:57 AM, nicolas cellier wrote:
 
 > However Markus, defensive programming is just a style, not a bad  
 > style, but
 > not the only one and not the most adequate in every case. There are  
 > many
 > cases where optimistic programming is better, when failure cases  
 > are so
 > unprobable that it would be a waste of time to repeatidly test costly
 > assertions (also better regarding volume of code). Exceptions find  
 > their
 > place here.
 
 If you prefer corrupted data in your database over a a slower or  
 error throwing program (*) you could always switch off the assertions  
 in your production system later without any loss of performance:
 http://www.whysmalltalk.com/articles/bykov/HitchHiker.htm
 
 Implemented/ported by Romain Robbes:
 http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-March/ 
 075327.html
 
 Cheers,
 
 Markus
 
 (*) You might be in a project phase, where your project leader  
 politically prefers bad data in the db than walkback screens in the  
 face of the end users.
 At least I experienced such kind of a project once... ;-)
 
________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060317/3f616129/attachment.htm