Luke Palmer <[EMAIL PROTECTED]> writes:
>> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>> Date: Tue, 15 Oct 2002 14:33:28 -0400
>
> I like the idea of this. The finer details, like returning what to
> do, could be more elegant. But the extensibility idea is golden.
>
>> To change how certain exceptions behave, a block simply changes the methods
>> of the existing ExceptionCreator to point to other subroutines. This
>> approach allows for an ala carte style of exception configuration. Blocks
>> can (through a module that makes this sort of thing easy), clone the
>> ExceptionCreator object, then change just the methods that are desired. A
>> reference to that new object is passed down the line to child blocks.
>
> I think a clone should be implicit (and lazy). Exception handlers
> should be lexically (or dynamically?) scoped. Dynamically could be
> useful in that if a module generated some known exception, you could
> tell it what to do---on it's level. I worry that this could break
> things too easily, though.
>
> I definitely like this idea in that it eliminates a lot of
> redundancy. Instead of 10 CATCH blocks doing the same thing with
> different names, you just have one handler that does it all.
> Exceptions are always something that seemed tedious to me (though I
> have had some fun with them), and this might possibly relieve that.
If you have 10 different exceptions that you want to handle in the
same way then you should probably look at subclassing them. Then all
you have to do is
try {
...
CATCH MyExceptionParent { ... }
}
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
