Chaim Frenkel wrote:
>
> Dave Rolsky wrote:
> >
> > Chiam Frenkel wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > try { my $p = P->new;
> > > > my $q = Q->new;
> > > > ...
> > > > }
> > > > finally { $p and $p->Done; }
> > > > finally { $q and $q->Done; }
> > >
> > > Could you tell me why you would want two finallys?
> > > Why not put them into one?
> >
> > Presumably because all finally blocks are executed [as]
> > exceptions thrown in finally blocks are propagated upwards.
>
> Syntactically the have to be next to one another, so write
> them as one.
If you write this:
try { my $p = P->new;
my $q = Q->new;
}
finally { $p->Done;
$q->Done;
}
what happens if both constructors succeed, but $p->Done dies?
"Brust, Corwin" wrote:
>
> I think the point is that a statment in the first finally block
> could throw, which would halt execution of that (first) finally
> block, at that point. Reguardless of weather that were caught the
> following finally block would be executed.
>
> try { &punt }
> catch { &punt_again }
> finally { &keeps_punting }
> finally { &does_this_anyway }
>
> I may well have missed somthing, but that's what I think Tony was
> aiming for.
Yes. Sorry I wasn't more clear. RFC 88 does say:
finally { ... }
Once the try block is entered, every finally block is guaranteed
to be entered before the try statement completes, whether or not
any exceptions have been raised since the try block was entered.
and it gives this example:
try { my $p = P->new; my $q = Q->new; ... }
finally { $p and $p->Done; }
finally { $q and $q->Done; }
This construct makes sure that if $q is successfully
constructed, then $q->Done is invoked even if $p->Done
raises an exception. Works with a pair of files too.
Yours, &c, Tony Olekshy
