Fun with Number readFrom: What should we do ?

ncellier@ifrance.com ncellier at ifrance.com
Thu Apr 27 14:13:32 UTC 2006


I agree with your example, but not with your words.

You don't know whether you can read a double or not in advance.
So what you do ?
You don't test if you can read a number as a precondition, because that would be the same as duplicating a large part of Number readFrom: code.
 What you do instead is trial and error. You're trying to read a Number, if it fails you do another thing.
Exception are well fitted for that case.

What i proposed readFrom:ifFail: is exactly corresponding to trial and error approach

Nicolas
 

Martin Wirblat:
 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
 > 
 > 
 > 
 
 
________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060427/e1c5bc01/attachment.htm


More information about the Squeak-dev mailing list