Jonathan Scott Duff wrote:
> 
> What's wrong with just using the switch statement?  It seems
> like except and catch are becoming special-purpose switches
> to me.  Is it really necessary?

It's not necessary, but it is the whole point of it all.

Try is "just" a special-purpose if, except is a special-purpose
else if, catch is a special-purpose else, as is finally.  Breaking
the local flow of control in a program is itself special purpose.

The special-purposeness is that these constructs have unwind
semantics.  That is, an except clause is only true if
we_are_already_unwinding_and the given block returns true.  The
catch/finally clauses are like else if and else blocks, but
unwinding from the block is trapped for further processing, and
finally actually happens always, not otherwise.

So sure you can do all this without any specific infrastructure
support for the unwinding-semantics control structures, just use
eval, die, and $@ and be sure to trap and handle unwinding from
all your except, catch, and finally equivalents.  In fact,

    try     { may_throw_1 }
    except  { may_throw_2 } => catch { may_throw_3 }
    finally { may_throw_4 }

can be written, without specific unwinding-semantics control
structures, just like this:

    eval { may_throw_1 };
    my $unwinding = $@;
    if ($unwinding) {
        my $test = eval { may_throw_2 };
        $@ and $unwinding = $@;
        if ( ! $@ and $test ) {
            eval { may_throw_3 };
            $unwinding = $@;
            }
        }
    eval { may_throw_4 };
    ($unwinding ||= $@) and die $unwinding;

which is pretty much what the Try.pm module referenced in RFC 88
does for you.  So really, the only difference is that the unwind-
semantics control structures save you 62 - 17 = 45 tokens, and
some opportunity to get the logic wrong.  Of course, getting the
logic wrong to the extent of accidentally dropping an exception
being used to report an assertion failure (ie, dropping an error)
can be catastrophic, so maybe the difference isn't trivial.

Also note that with manual implementation of exception handling,
you don't get any unwind-time trace-back debugging info either,
which RFC 88 does for you.  When you start using this a lot (and
you will, if Perl 6 goes to internal exceptions for fatal errors),
you'll quickly find you're glad to have this "special purpose"
information.

Yours, &c, Tony Olekshy

Reply via email to