Cesar, Good point. Exception handling code even when using simple class-based exceptions and exception sets does indeed devolve into CaseOf constructs. Using classes, the following code is still common: [ (RangeError new) signal: 'access out of bounds' ] on: Error do: [:ex | (ex isKindOf: RangeError) ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]]. and using ExceptionSets doesn't lead to anything better. At GemStone we _have_ added an extention that looks something like the following to get away from explicit CaseOf code: [ (NumericError new) reason: #rangeError; signal: 'access out of bounds' ] onExceptions: NaNError, RangeError do: { [:naNError | "do something with NANError"]. [:rangeError | "o something with RangeError"]. }. but it's just a different form of CaseOf...I don't think the use of reasonCodes is the cause... To get around this, I guess you'd have to start extending various Exception classes with "handler-specific" methods that would allow you to double dispatch your way out of the CaseOf construct... Dale n 04/14/2011 12:38 PM, csrabak@bol.com.br wrote:
Not willing to rattle cages, reading this particular set of postings I wonder if its my sole feeling or this kind of code 'leads to' naturally to a screaming need for a CaseOf construct?
In the snippet below submitted by Dale if we have some other [expected] numeric errors (a.k.a. 'reasons') you would end up with a very hairy entanglement of ifTrue:[]ifFalse:[], wouldn't you?
my 0.01999.....
-- Cesar Rabak
Em 14/04/2011 15:52, Dale Henrichs< dhenrich@vmware.com> escreveu: Stef,
For rangeError the code would look like this:
[ (NumericError new) reason: #rangeError; signal: 'access out of bounds' ] on: NumericError do: [:ex | ex reasonCode == #rangeError ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]].
Dale
On 04/14/2011 11:13 AM, Stéphane Ducasse wrote:
Dale
so it means that I write what?
[] on: NumericError do: [:ex | ]
how do I access the rangeError?
Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class):
Exception (messageText reasonCode) Abort Error NumericError #floatingPointException #rangeError #naNError ZeroDivide (dividend) FileStreamException (fileName) #fileDoesNotExistException #fileExistsException (fileClass) #cannotDeleteFileException #fileWriteError #fileReadError ** #fileClosedException ** #cannotAccessFileException ** #readonlyFileException ** MessageNotUnderstood (message, receiver) #nonBooleanReceiver (object) OutOfMemory< handlers?> ControlInterrupt Halt AssertionFailure BreakPoint CompileError SyntaxError ** !exists! (input, position) #numberFormatException ** #headlessError ** TimedOut ** (object, operation, timeout) VerificationException IllegalOperation ** (operation, object) #sizeMismatch (objects) #subclassResponsibility ** (message, receiver) #notYetImplemented ** (message, receiver) #cannotInstanciate ** (class) #readOnlyObject ** (object) OutOfFreeSpace ** #invalidArgument ** (message, receiver, argument) #notIndexable ** (object) #noKeyedAccess ** (object) #nonIntegerIndex ** (receiver, index) #subscriptOutOfBounds ** (receiver, index, from, to) NotFoundException ** (receiver, object) #keyNotFound ** #valueNotFound ** #elementNotFound ** StreamException (stream) #positionError ** (index, from, to) EndOfStream ** #beginOfStream **
Notification Admonition LowMemory **