[Pharo-project] Improving Pharo's Exception Hierarchy

Dale Henrichs dhenrich at vmware.com
Thu Apr 14 22:05:17 CEST 2011


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 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:
> 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 **
>>>
>>
>>
>
>
>
>




More information about the Pharo-project mailing list