Some discussion has suggested that it might be a good idea if it
were possible to have a simple way to prevent catch from catching
so-called "fatal" errors. Some fringe ideas have actually included
two seperate mechanisms, one for so-called fatal errors (based on
die), and one for so-called non-fatal errors (based on throw).
Careful reading of RFC 88 shows that the following already works
for the purpose described above:
try on_catch_enter => sub { $@->fatal and throw $@ },
{
$test == 0 and do { my $x = 0; my $y = 1 / $x; };
$test == 1 and do { open F, "this-file-no-exists"; };
}
catch { # A
}
$test 0 will never be caught by catch A, because (assuming its
divide-by-zero exception is marked with severity => "fatal") the
on_catch_enter callback will pick that off and re-raise $@ before
catch A even gets entered! Try's callback hooks are defined to be
dynamically scoped, so this applies to all severity eq "fatal"
anywhere under the try in the call stack. A lower-level try can
turn off an outer callback like this:
try on_catch_enter => sub { }, { ... }
Now, all this illustrates exactly why "fatal" isn't special,
because the types of exceptions to be automatically skipped by
catch clauses is the business of the catcher, not the thrower.
I might want to define only a handful of exceptions, or a more
inclusive set of exceptions, that I don't want to be catchable.
So I define a too_severe method for the Exception class, and say
try on_catch_enter => sub { $@->too_severe and throw $@ },
{
}
catch {
}
Finally, consider this case. Say someone wants a pragma to turn
this sort of no-catch-when fatal behaviour on or off. If they
change the state of the pragma, say for debugging purposes, they
must also find every die and throw and change them into throw and
die (instead of just changing their top-level on_catch_enter
callback, or a "global" flag tested in it).
The reason so much heat is being generated by some of the
discussions in -errors is because the merits of one approach
over another are being debated by approach afficionados, none
of whom wish to see their familiar technique obsoleted.
In the author's humble opinion, our time might be better spent
working to clean up the details and presentation of a clean but
extensible infrastructure mechanism that can be freely used by
all in the fashion to which they have been accustomed. We can
work out the syntactic sugar and command line flags as we go.
That, after all, is really the Perl way.
Yours, &c, Tony Olekshy
