Fun with Number readFrom: What should we do ?

nicolas cellier ncellier at ifrance.com
Fri Apr 28 19:26:34 UTC 2006


>
> I want to parse 1.23 and that is not a Smalltalk number, it is a number.
> If I read '' from a csv file, from a user input or a free-form text as
> what could or should be a number, the data point is undefined, and nil
> is expressing that literally.
>

Hi Martin,
I persist to think that getting a nil is rarely the aimed feature, and it will 
mostly be used as a C-style way to indicate a failure (exactly like fopen() 
returning NULL).
As Andreas suggested, browse senders of readFrom: in a 3.9 image, and tell us 
where a nil answer would make sense.

Doing so, you will notice a single ifError: [].
What we can conclude is that no-one is prepared for the possibility of 
failure... So, some code might have to be debugged anyway when we change the 
behavior and do not answer 0 anymore. (or maybe we will found so far hidden 
bugs).

If we adopt ^nil, methods will not fail while reading, they will fail latter 
when using the value, and that may be far latter, making the bug less 
explicit to track.
This is true for future code also, we are all either lazy, or not prepared to 
write C-style-code, and a few will assert ifNil:.

If we adopt the exception, the method will fail, but with debugger opened 
exactly at the place where the origin of the problem is.

And if you really want the nil, no problem, you write
    value := [Number readFrom: stream] ifError: [nil].
With a resumable exception, you can easily catch that once for all
    [ MyCvsApp doSomething ] on: NumberParsingError do: [:exc | exc resume: 
nil].

One can also resume: 0, if one's app requires this as a feature...

Sorry that you have to write extra-code, but it seems that our laziness is 
superior to yours...

Nicolas




More information about the Squeak-dev mailing list