Tony Olekshy wrote:
> 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).
Say, at least you didn't use the word "lunatic" to modify "fringe" :)
> 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 { }, { ... }
So it becomes important to always set the hooks the way you expect them
to be set, because you can never be sure what someone above you might
have done. So, at least in the set of interface APIs for each module,
careful reading of RFC 88 implies it is important not just to say "try"
to catch errors, but to say instead:
try on_catch_enter => sub { ... },
on_throw_enter => sub { ... },
on_catch => sub { ... },
on_catch_exit => sub { ... },
on_throw_exit => sub { ... },
on_raise => sub { ... },
on_finally_enter => { ... },
on_finally_exit => { ... },
{ ...
} catch ...
Or maybe I didn't read carefully enough, and there is more? Otherwise,
the code is subject to "action at a distance" problems with outer scopes
that modify some of the hooks. Friendly!
I'm less enamored of this technique when awake than I was last night
when I was sleepy. It sounded good on the surface until I recognized
that the hooks are "action at a distance" hooks, and that they must all
be specified to guarantee expected behavior of a module. That is gross.
> 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).
I don't understand the above paragraph. Why, when changing a pragma,
would every die and throw have to change?
> 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.
Maybe you are correct, there, but by proposing a new, orthogonal
technique in RFC 119, RFC 119 is not obsoleting any of familiar
techniques... 100% of them will continue to work unchanged--although
there would then be better ways to do some things. By building up a
non-fatal error handling technique on top the existing fatal error
handling technique, you are forcing code that assumes it will die to
behave differently, when you wrap a try block around it. Now it will
only "maybe" die. Whether "die" was necessary or appropriate to the
situation being dealt with is a different discussion. Whether the code
continues to work as expected or not is a compatibility issue.
> 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.
This is a great goal, Tony. Let's keep at it.
> That, after all, is really the Perl way.
>
> Yours, &c, Tony Olekshy
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
