I agree with your example, but not with your words.<br /><br />You don't know whether you can read a double or not in advance.<br />So what you do ?<br />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.<br /> What you do instead is trial and error. You're trying to read a Number, if it fails you do another thing.<br />Exception are well fitted for that case.<br /><br />What i proposed readFrom:ifFail: is exactly corresponding to trial and error approach<br /><br />Nicolas<br /> <br /><br />Martin Wirblat:<br /> <blockquote style="border-left: 1px solid blue; border-right: 1px solid blue; margin: 10px">Nicolas,<br /> <br /> you are arguing form the premise that some string that is not <br /> convertible to a float is a problem, an error or an exception. Consider <br /> a csv file. You would read it with upTo: $;. If you get an empty string <br /> it does not mean that an
error occurred, it means that a piece of <br /> information is not applicable or available. That is valid information <br /> and not an error! There are csv files with more than 99% of such empty <br /> fields.<br /> <br /> The same holds true for an unformatted text from which information has <br /> to be extracted. It is expected that at many places a piece of <br /> information may or may not appear. And because it is expected it can't <br /> be an exception ;)<br /> <br /> I think if a string can't be converted to a float almost never an error <br /> should be raised. And if so, some very specific reason has to exist, <br /> some reason that makes this scenario a real - unforeseeable - error.<br /> <br /> For me the bottom line of the 'exception thread' was exactly this: an <br /> error or an exception is something which is unforeseeable. If you can <br /> predict that it may happen or if it regularly happens it should get <br /> handled directly.<br /> <
br /> Perhaps even more straight: If *possible* it should be handled directly. <br /> Error handlers are reserved for cases where you don't know when or where <br /> exactly what may go wrong.<br /> <br /> Regards,<br /> Martin<br /> <br /> <br /> nicolas cellier wrote:<br /> > Le Jeudi 27 Avril 2006 12:14, vous avez écrit :<br /> > <br /> >>nicolas cellier wrote:<br /> >>...<br /> >><br /> >><br /> >>>What do you vote for ? exception, answering 0, any other idea ?<br /> >>>What to do with the stream in case of error ? rewind, keep in place ?<br /> >>>I'am waiting for your comments.<br /> >><br /> >>Answering nil of course. To answer 0 is outright wrong and raising an<br /> >>exception is at least to cumbersome. One could rate it being wrong too,<br /> >>because unknown text that has to be converted is a valid input, and thus<br /> >>finding no correct float is a valid resul
t - nil.<br /> >><br /> >>Regards,<br /> >>Martin<br /> > <br /> > <br /> > Hi Martin<br /> > Of course, answering nil is an obvious possibility better than answering 0.<br /> > I longly used this construction before i discovered exceptions, and i will try <br /> > to explain why i have switched to this second preferable style.<br /> > <br /> > Answering nil is exactly the policy adopted in C programs.<br /> > It means that when you write a line of code, you will have 3 lines following <br /> > for handling problems.<br /> > If you omit this post-checking, your C programs can have weird behaviours like <br /> > dumping a core later when uninitialzed values will be used...<br /> > <br /> > The FORTRAN way was better (i think of the READ() instruction):<br /> > - default was to abort the program with an error message (brutal but clean)<br /> > - it was possible to pass a label to branch on in case of error (an e
arly <br /> > exception handling mechanism).<br /> > <br /> > In Smalltalk, we have those nice soft aborption with debugger, better than a <br /> > core dumped, but that does not solve everything, and in fact we face the same <br /> > choice that C-FORTRAN explained above:<br /> > <br /> > Suppose we adopt the nil answer.<br /> > We will have to check for nil after each readFrom: instruction.<br /> > If we lazily omit those nil-checking lines, the problem can appear well later <br /> > in the code when we will try and use the value, and the debugger will not be <br /> > of much use, because it won't point directly at the place where the problem <br /> > come from (the C core dumped case)...<br /> > <br /> > If i have a method with 10 readFrom: , i will have 10 ifNil: blocks for <br /> > handling the exception.<br /> > Maybe the handling can consist simply in answering nil in our turn and reject <br /> > the problem to th
e sender method, wich will have to check ifNil: in its turn <br /> > und so weiter...<br /> > What i dislike in this C-style is that it makes code less readable because <br /> > main algorithm is scattered among exception handling code.<br /> > <br /> > Suppose now we adopt an exception mechanism.<br /> > I am lazy and do not put an exception handling block (working on a prototype). <br /> > Then the debugger will open exactly where the problem occured.<br /> > I am smarter with the users of my programs and provide an exception handling <br /> > block: then i can factor several exceptions in a single block (the case when <br /> > i do 10 readFrom:), and i can handle the problem several senders above <br /> > without adding noisy ifNil: at each level.<br /> > <br /> > The problem with exception is that if i trap Error, i will trap too many <br /> > errors, not only the readFrom: error. This is not selective enough. This has <br /> >
; already been discussed on the list, when to create a new exception class ? <br /> > but i do not have the feeling we got a clear answer...<br /> > Untill we address this problem, your ^nil proposition is a candidate though <br /> > not my favourite style. Maybe readFrom: can also call readFrom:ifFail: the <br /> > way Dictionary at: call at:ifAbsent:.<br /> > <br /> > Nicolas<br /> > <br /> > <br /> > <br /> <br /> </blockquote>
<br><br><hr style="border:0;height:1px;color:#d1d1db;background-color:#d1d1db;">
<table cellpadding=0 cellspacing=0><tr><td><a href="http://web.ifrance.com/"><img border=0 align=left src="http://image.ifrance.com/mail/colibri.gif"></a></td>
<td style="line-height:7px"><a href="http://web.ifrance.com/" style="line-height:11px;font-family:arial;font-size:11px;color:#1b174a;text-decoration:none"><b><span style="color:#9b90d5">i</span>FRANCE</b></a>
<br><a href="http://web.ifrance.com/services/" style="line-height:6px;font-family:arial;font-size:11px;color:#1b174a;text-decoration:none">exprimez-vous !</a></td></tr></table>