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, [email protected] 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< [email protected]> 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 **
