[Pharo-project] Improving Pharo's Exception Hierarchy
dhenrich at vmware.com
Thu Apr 14 22:05:17 CEST 2011
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'
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:
signal: 'access out of bounds'
onExceptions: NaNError, RangeError
[: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...
n 04/14/2011 12:38 PM, csrabak at 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 at vmware.com> escreveu:
> 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 ]].
> On 04/14/2011 11:13 AM, Stéphane Ducasse wrote:
>> 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 **
More information about the Pharo-project