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
|