Fun with Number readFrom: What should we do ?

Andreas Raab andreas.raab at gmx.de
Thu Apr 27 18:34:57 UTC 2006


The example of the csv file is very badly chosen IMO. CSV files contain 
many different things and applying the same logic you are using for 
numbers here would dictate that String>>readFrom: also answer nil when 
trying to read from an empty string. Moreover, it would dictate that 
Strings use double quotes (if I remember my .csv corretly). This has 
nothing to do with the discussion here - .csv files do NOT contain 
"Smalltalk numbers" so to speak, therefore they need to be separately 
parsed and analyzed and arguing that an empty string should parse as nil 
because .csv files have empty fields is really besides the point of this 
discussion.

Number>>readFrom: has the specific intent to read a literal number from 
a stream. I have yet to find a caller that could even deal with the fact 
that this method may answer nil. This goes mostly to show at what a low 
level number parsing is typically used (e.g., all the error checking 
happens mostly at a higher level) which speaks very clearly for having 
an exception raised to signal the problem.

@Nicolas: I find your proposal of readFrom:ifFail: to be somewhat 
overkill. An exception/error seems simpler and more direct to me.

Cheers,
   - Andreas


Martin Wirblat wrote:
> Nicolas,
> 
> you are arguing form the premise that some string that is not 
> convertible to a float is a problem, an error or an exception. Consider 
> a csv file. You would read it with upTo: $;. If you get an empty string 
> it does not mean that an error occurred, it means that a piece of 
> information is not applicable or available. That is valid information 
> and not an error! There are csv files with more than 99% of such empty 
> fields.
> 
> The same holds true for an unformatted text from which information has 
> to be extracted. It is expected that at many places a piece of 
> information may or may not appear. And because it is expected it can't 
> be an exception ;)
> 
> I think if a string can't be converted to a float almost never an error 
> should be raised. And if so, some very specific reason has to exist, 
> some reason that makes this scenario a real - unforeseeable - error.
> 
> For me the bottom line of the 'exception thread' was exactly this: an 
> error or an exception is something which is unforeseeable. If you can 
> predict that it may happen or if it regularly happens it should get 
> handled directly.
> 
> Perhaps even more straight: If *possible* it should be handled directly. 
> Error handlers are reserved for cases where you don't know when or where 
> exactly what may go wrong.
> 
> Regards,
> Martin
> 
> 
> nicolas cellier wrote:
>> 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