> Glenn Linderman wrote:
>
> I'm now reaching the conclusion that RFC 88 is apparently building
> more mechanism around item 2 to make it prettier for use as a
> general exception mechanism. If so, I don't think that is a
> good idea.
In some ways you are oversimplifying the problem, and in other
ways it's less complex than you think. The main things to keep
in mind are that exceptions and errors aren't the same thing,
that exceptions are just one way of signalling errors, and that
exceptions can be used for signalling things other than errors
(such as success).
> Separate mechanisms should be used for clarity and compatibility.
I agree if you mean that non-local flow control mechanisms (ie,
exception handling) should be seperate from local flow control
mechanisms, which RFC 88 does propose. But if you mean that the
*mechanism* for non-local flow control for what you deem to be
"fatal error" exceptions should be different from that for which
you mean "non-fatal error", then I disagree. Remember, it's up
the catcher to determine whether or not an exception should be
considered an error, and if so, whether or not it should be fatal.
If the the thrower already knew that, in many cases they wouldn't
have to throw at all.
> But on the other hand, if you really want to trap both fatal and
> non-fatal errors, doing it via a single general exception
> mechanism is nice. How can we achieve both?
RFC 88 already achieves both, like this:
catch $@->{severity} eq "Fatal" => { ... }
We could certainly add a $@->fatal predicate for you to make this
even easier.
catch $@->fatal => { ... }
> Perhaps p52p6 should have an option to automatically convert
> die/eval to catch/throw. An option, because it won't be able to
> tell the difference between fatal and non-fatal either, so the
> user would have to choose which set is smaller, to convert by
> hand after p52p6 is done.
RFC 88 doesn't change the way die or eval work, so why would you
want to automatically convert them to throw and catch? Remeber that
any RFC which proposes that traditional Perl code will not longer
work traditionally, by default, is going to have a hard time with
many people, including me. That's why RFC 88 explicitly doesn't
suggest any such thing.
Yours, &c, Tony Olekshy
