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
|