About use of specific error
nicolas cellier
ncellier at ifrance.com
Fri Mar 17 02:57:04 UTC 2006
Sorry i missed this very interesting discussion, but some trivial thoughts
deserve to be recalled.
Sure exceptions were built in C++ java world...
Sure Smalltalk has alternate solutions thanks to block non local return.
( Compiler evaluate: 'bla + + bla' ifFail: [^nil] is even better example than
at:ifabsent: because it uses a non local block return).
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.
Of course, exception is particularly usefull for exception handling in long
call chains, where passing block or any other handler as extra argument is
the last thing wanted. I guess also very few Smalltalkers would be happy
testing for error return in the whole call graph like C-style code.
---------------------------------------
As a perfect example, we can think of arithmetic exception handling (overflow,
underflow, division by zero, domain error...). I would like to have these
exceptions in Squeak like they exist in VW. Unfortunately, Squeak use the
perverse IEEE NaN and Inf... In my opinion, this is rarely wanted and most
people would prefer a program to stop with an exception rather than having
these needless computations silently proceeding with NaNs. Beside it is then
difficult to find the originator of the error. Last, overflow does not really
match mathematical notion of infinity, i think confusion is dangerous here...
In some cases i would catch such an overflow and retry with another algorithm,
or switch from float32 to float64, or maybe my own LargeFloat like there are
LargeInteger... This is where i like having specific errors.
Maybe in another case, i can catch any kind of arithmetic error and restart
another algorithm, and then, yes Andreas, error hierarchy can be usefull
(though there are alternate solutions like handling error collections).
Then what are the guidelines that will prevent hundreds of Exceptions from
populating the hierarchy ? We should answer this question... unless we feel
comfortable with hundreds of classes.
To continue with arithmetic case, defensive tests are done either at VM level
and/or at hardware level, it would be so costly to duplicate them at
Smalltalk level ! Beside, no one is ready to transform all these + * - / into
plus:iffail: etc... Obviously, handling cannot be local and handler cannot be
passed as argument, exceptions are definitly a must here.
That also suggest one of the guidelines: the low level exceptions tested in
the VM should have a correspondance in the Error hierarchy (if they have a
failBlock argument, default block should signal a specific exception).
Lets return to arithmetic exceptions, I would really like to have them instead
of silent NaNs/Inf. NaN should be a way of handling arithmetic exception, but
not the preferred way. Anyone disagree ?
Nicolas
More information about the Squeak-dev
mailing list
|