Redirected to perl6-language-flow.
At 10:39 AM 8/11/00 -0400, John Porter wrote:
>Piers Cawley wrote:
> >
> > The (continue|always|finally|whatever) clause will *always* be
> > executed, even if one of the catch clauses does a die, so you can use
> > this to roll back the database transaction or whatever else was going
> > on and restore any invariants.
>
>Which makes me think that it would be nice if the continue block could
>come before the catch block(s):
>
> establish_invariants();
> try {
> something_risky();
> }
> continue {
> restore_invariants();
> }
> catch {
> handle_error_assuming_invariants_restored();
> }
I get where you're going with this but it breaks the paradigm too
much. Now you need a 'finally' block again.
Arguably some provision should have been made for this in Java/C++ (I'm not
totally familiar with those languages, so if I'm wrong, someone could point
it out and the answer could be useful). But they are somewhat less
adventurous about reinventing their languages :-)
The only point of using the continue block as you suggest is if there are
multiple catch blocks, otherwise you'd just do
try { } catch { restore_invariants(); handle_error_etc(); }
You could do
try { } catch { restore_invariants(); $err = shift; switch ($err)
{ ... } }
I can hear the howls about that's just like other people were proposing
earlier, and so what's the point of the catch keyword. However, I would
contend that in practice, restore_invariants() will depend on the type of
exception thrown, and you would invariably :-) have a different one for
each catch block:
try {
something_risky();
}
catch Exception::Foo {
restore_foo_invariants();
handle_error();
}
catch Exception::bar {
restore_bar_invariants();
handle_error();
}
catch {
restore_invariants_if_you_can_figure_them_out();
probably_die_anyway();
}
--
Peter Scott
Pacific Systems Design Technologies
