R1) RATIONALE FOR HAVING AN EXCEPTION RAISED BY DEFAULT:
The Smalltalk way is the lazy way: raise an Exception, let it
unhandled and let user interact in the Debugger to understand what
went wrong. This work best if the Exception is raised soon after the
error conditions, and that is why I generally prefer raising an
Exception than answering nil, or even worse zero!
R2) RATIONALE FOR HAVING PROGRAMMABLE ERROR:
For a closed source application, you'll have to implement your own
error handling...
...and the Kernel should propose, not impose the implementation style:
- Exception handling ([] ifError: [], [] on: Error do: [:exc | ])
- exception block argument (at:ifAbsent:, readFrom:ifFail:)
- isNil ifTrue: [] (very C-stylish)
STATUS OF CURRENT IMPLEMENTATION:
When reading fail for any reason then:
SqNumberParser>>fail
failBlock isNil ifFalse: [^failBlock value].
self error: 'Reading a number failed'
Default behaviour is to raise an Exception.
But SqNumberParser is programmable via failBlock.
And this is used to answer 0 in case of failure...
Number class>>readFrom: stringOrStream
"Answer a number as described on aStream. The number may
be any accepted Smalltalk literal Number format.
It can include a leading radix specification, as in 16rFADE.
It can as well be NaN, Infinity or -Infinity for conveniency.
If stringOrStream does not start with a valid number description,
answer 0 for backward compatibility. This is not clever and should
better be changed."
^(SqNumberParser on: stringOrStream) failBlock: [^0]; nextNumber
Unless you use the dedicated programmable entry point:
Number class>>readFrom: stringOrStream ifFail: aBlock
"Answer a number as described on aStream. The number may
be any accepted Smalltalk literal Number format.
It can include a leading radix specification, as in 16rFADE.
It can as well be NaN, Infinity or -Infinity for conveniency.
If input does not represent a valid number, then execute fail block
and leave the stream positioned before offending character"
^(SqNumberParser on: stringOrStream) failBlock: aBlock; nextNumber
CONCLUSION AND TODO:
1) R1 is not fulfilled, so better raise an Exception than answer zero
2) R2 is already fulfilled, just open a browser and see by yourself
3) Eventually create a dedicated exception like NumberParsingError...
Nicolas
2009/9/24 Schwab,Wilhelm K <[email protected]>:
> Nicolas,
>
> Silent failures are **BAD**. I always like to compare things to #at: and
> #at:ifAbsent:. #at: will answer the indicated item or raise an exception.
> #at:ifAbsent: allows one to customize the behavior and w/o the expense of
> setting up an exception handler, which is great if the error (bounds in this
> case) can be understood and corrected locally. Of course, structured
> exceptions arose to handle the common situation in which I find an error but
> only you can tell what to do about it, and we are working on completely
> different parts of the system.
>
> This whole debate arises again with end-of-stream exceptions:
>
> http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware
>
> I am using the additional protocol approach with good results, but should try
> to make some time to test your pluggable exception idea.
>
> Bill
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Nicolas
> Cellier
> Sent: Thursday, September 24, 2009 3:19 AM
> To: [email protected]
> Subject: Re: [Pharo-project] '.2e2' asNumber ?
>
> The two problems were identified from the beginning:
>
> 1) 2.e5 and .2 did work in old squeak images, but no more with SqNumberParser
> Rationale: SqNumberParser is for parsing number literals in squeak syntax,
> and those extensions are not identified squeak syntax
>
> If you need these syntax, the best thing is to subclass the NumberParser. For
> example, I must have a FORTRANNumberParser available somewhere...
>
> 2) Silently returning zero in case of error.
> This was one of the goal of SqNumberParser: let programmer choose the
> appropriate behaviour
> - raise an Exception
> - answer nil
> - answer a default value (zero)
> The last solution has been connected to Number class>>#readFrom: for
> historical compatibility reasons.
> I agree this conservative choice was unfortunate.
> Pharo should not fear and break compatibility on such dumb behaviours.
>
> Nicolas
>
> 2009/9/24 Stéphane Ducasse <[email protected]>:
>> I imagine that nicolas will let us know.
>> If you have tests we would love to integrate them so that we can
>> detect that.
>>
>> Stef
>>
>> On Sep 23, 2009, at 11:25 PM, John M McIntosh wrote:
>>
>>> I noticed that in Squeak and earlier version of Pharo doing '.2e2'
>>> asNumber would return 20.0 or '.2' asNumber would return 0.2
>>>
>>> but currently in Pharo those return 0, without error, comment, or
>>> other hand waving.
>>> Good thing I have Sunits...
>>>
>>> So is this a bug or feature?
>>>
>>> Hint obviously in the Fractions calculator people are lazy and enter .
>>> 2e2 or .2 without the leading zero...
>>>
>>> --
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =====================================================================
>>> = John M. McIntosh <[email protected]> Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd. http://
>>> www.smalltalkconsulting.com = = = = =
>>> =====================================================================
>>> =
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
