Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > 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.
They don't have to. They can just use a try with an empty catch,
which is what Peter and I wanted in the first place.
I was only pointing out that there are two camps involved here,
one of which likes eval semantics and the other which likes try
semantics. If we leave eval alone in Perl 6, and add try, then
everyone should be happy, and there will be one less potential
problem converting Perl 5 code. We may need not even need to add
try to the Perl guts (RFC 88 as implemented in Perl 5 is a module
that adds try, so perhaps all we need is a core module and possibly
an efficiency hook or two).
> 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;
>
> And the dispatcher would look first in the object, then in the
> class for uncaught_handler.
Ideas about exceptions and exception handling are easy. Getting a
suite of ideas to cooperate in practice can be more difficult. For
example, with
try { throw Exception1->New; }
catch { throw Exception2->New; }
does the uncaught_handler of Exception1 get called? One could say,
"no, because it was caught", or "yes, because it wasn't fully
caught, because the catch didn't complete".
And by the way, what's supposed to happen when an uncaught_handler
throws?
I'd like to see some working code excercising uncaught_handler, with
documentation and regression tests I can study. One could base such
an implementation in the code referenced in RFC 88.
> I think it's cool how this process is converging :-)
Yes, but let's not get carried away. We have to try to come up with
a clean set of basic concepts that work well in the easy easy, hard
possible sense. If we want to use unwinding with exception objects
as the basis for Perl's failure handling, then we *certainly* don't
want a fragile exception handling mechanism compounding the failure
for us. What is the cost of an accidentally lost throw when you are
using exception handling for error handling? As Henry Spencer used
to say, "then all bets are off".
If you don't like food-for-thought digressions, skip this paragraph.
Say you and I are playing a game of catch (the verb). We can throw
a football, or a baseball, or a frisbee, all using the same basic
throwing and catching mechanism. We can teach that mechanism how to
handle different classes of throwable-catachables, but we can't
teach it to throw or catch 16T blocks. And in no case is the object
being thrown allowed to reach out and change my hand into a foot.
Yours, &c, Tony Olekshy
