Fun with Number readFrom: What should we do ?

nicolas cellier ncellier at ifrance.com
Thu Apr 27 11:55:30 UTC 2006


Le Jeudi 27 Avril 2006 12:14, vous avez écrit :
> nicolas cellier wrote:
> ...
>
> > What do you vote for ? exception, answering 0, any other idea ?
> > What to do with the stream in case of error ? rewind, keep in place ?
> > I'am waiting for your comments.
>
> Answering nil of course. To answer 0 is outright wrong and raising an
> exception is at least to cumbersome. One could rate it being wrong too,
> because unknown text that has to be converted is a valid input, and thus
> finding no correct float is a valid result - nil.
>
> Regards,
> Martin

Hi Martin
Of course, answering nil is an obvious possibility better than answering 0.
I longly used this construction before i discovered exceptions, and i will try 
to explain why i have switched to this second preferable style.

Answering nil is exactly the policy adopted in C programs.
It means that when you write a line of code, you will have 3 lines following 
for handling problems.
If you omit this post-checking, your C programs can have weird behaviours like 
dumping a core later when uninitialzed values will be used...

The FORTRAN way was better (i think of the READ() instruction):
- default was to abort the program with an error message (brutal but clean)
- it was possible to pass a label to branch on in case of error (an early 
exception handling mechanism).

In Smalltalk, we have those nice soft aborption with debugger, better than a 
core dumped, but that does not solve everything, and in fact we face the same 
choice that C-FORTRAN explained above:

Suppose we adopt the nil answer.
We will have to check for nil after each readFrom: instruction.
If we lazily omit those nil-checking lines, the problem can appear well later 
in the code when we will try and use the value, and the debugger will not be 
of much use, because it won't point directly at the place where the problem 
come from (the C core dumped case)...

If i have a method with 10 readFrom: , i will have 10 ifNil: blocks for 
handling the exception.
Maybe the handling can consist simply in answering nil in our turn and reject 
the problem to the sender method, wich will have to check ifNil: in its turn 
und so weiter...
What i dislike in this C-style is that it makes code less readable because 
main algorithm is scattered among exception handling code.

Suppose now we adopt an exception mechanism.
I am lazy and do not put an exception handling block (working on a prototype). 
Then the debugger will open exactly where the problem occured.
I am smarter with the users of my programs and provide an exception handling 
block: then i can factor several exceptions in a single block (the case when 
i do 10 readFrom:), and i can handle the problem several senders above 
without adding noisy ifNil: at each level.

The problem with exception is that if i trap Error, i will trap too many 
errors, not only the readFrom: error. This is not selective enough. This has 
already been discussed on the list, when to create a new exception class ? 
but i do not have the feeling we got a clear answer...
Untill we address this problem, your ^nil proposition is a candidate though 
not my favourite style. Maybe readFrom: can also call readFrom:ifFail: the 
way Dictionary at: call at:ifAbsent:.

Nicolas




More information about the Squeak-dev mailing list