Fun with Number readFrom: What should we do ?

stéphane ducasse ducasse at iam.unibe.ch
Thu Apr 27 19:41:34 UTC 2006


Just to say that I really enjoy reading this discussion.
Please continue and conclude with some enh, fix and tests. Excellent!

On 27 avr. 06, at 20:34, Andreas Raab wrote:

> 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