About use of specific error
ncellier@ifrance.com
ncellier at ifrance.com
Fri Mar 17 14:49:51 UTC 2006
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
More information about the Squeak-dev
mailing list
|