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
|