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 <bschwab@anest.ufl.edu>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Thursday, September 24, 2009 3:19 AM To: Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr>:
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 <johnmci@smalltalkconsulting.com> Â Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. Â http:// www.smalltalkconsulting.com = = = = = ===================================================================== =
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project