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