At 05:22 AM 8/14/00 -0600, Tony Olekshy wrote:
>Graham Barr wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > I agree with Peter: use a try with an empty catch.
> >
> > That depends on how you think about things.
> >
> > Many people seem to be coming from the though of "I want to
> > catch these exceptions" where-as the current perl-like way
> > to do this is "I want to see what exceptions were thrown and
> > deal with them"
> >
> > In the first scenario an exception would look for a try that
> > explicitly states it cathes it. In the second an exception
> > will only go as far as the firt try{} on the stack and it is
> > upto that code to re-throw it.
> >
> > IMO, I prefer the second one although I could live with the first.
>
>When you want the first one, use try + catch.
>
>When you want the second one, use eval, then manipulate $@.
>Just be sure to arrange to handle exceptions while handling
>exceptions.
Erk, people shouldn't have to use such radically different syntax for a
tiny semantical change.
> > This difference should be listed in the RFC to allow Larry to
> > make his decision of which he wants.
>
>Or to keep both. I will list it in the RFC.
Everyone seems to have started thinking about the implication of
inheritance in exception classes at the same time. Whatever the default
behavior is, we can easily change it on a global basis (using Chaim
Frenkel's sub name here);
sub Exception::uncaught_handler { maybe rethrow, maybe not }
Or a per-class basis:
sub Exception::IO::uncaught_handler { ... }
Or a per-object basis (gross as I find this):
my $e = Exception::SQL->new(...);
$e->uncaught_handler = sub { ... }
throw $e; # or maybe throw Exception::SQL(uncaught_handler => sub { ...
}, ... );
And the dispatcher would look first in the object, then in the class for
uncaught_handler.
I think it's cool how this process is converging :-)
--
Peter Scott
Pacific Systems Design Technologies
