Tony Olekshy wrote:
> > 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).
I'd appreciate enlightenment as to where you think I'm oversimplifying
and where you think I'm overcomplicating, rather than just that bare
statement. Without that enlightenment, I'll have to respond based on my
current mindset, sorry. [Reading ahead regarding your two posts
responding to RFC 119v2, I suspect maybe some of this was due to your
misunderstanding of parts of RFC 119; no doubt I also still have some
misunderstandings of RFC 88; but that's why they are still two separate
RFCs, and we're still discussing them.]
I'm well aware that exceptions and errors aren't the same thing. I'm
also aware that fatal and non-fatal errors aren't the same thing.
I could say the same about you, but I'll give details: you are
oversimplifying fatal and non-fatal errors being handled the same way,
but overcomplicating the syntax needed to deal with them. I'll support
that latter half of the statement with the "multiple finally clause"
issue, that you've had to explain to multiple people:
While I think I understand the need for multiple finally clauses in RFC
88, many don't. I think the root cause is that the complete finally
code is bundled at the end of the try/catch stuff, and has to handle all
of the potentially many setup jobs done inside the try block.
Distributing the finally job among individual, scattered always clauses
(RFC 119 doesn't have a finally clause, but it talks about RFC 88's
finally clause; RFC 119's always clause corresponds, but is different
enough that I chose a different name) not only keeps the setup/cleanup
code together logically (which I like, and you've also claimed to like),
but also transparently satisfies the needs for which RFC 88 proposes and
shows examples of use of multiple finally clauses.
> > 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.
I meant the latter, so we disagree. In fact, you disagree internally
with yourself, in subsequent paragraphs....
> 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.
This is a nice motherhood statement, but later you contradict it...
> > 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 find that at least some errors have preclassified themselves as
fatal!
Hence, the thrower already knew it was fatal, so shouldn't have needed
to throw at all, rather it could just have died directly. Exactly the
same cause as the confusion between not checking return codes vs using
eval to catch fatal errors. Except that you've replaced die with throw
semantics, so here comes this fatal error up the stack.
> We could certainly add a $@->fatal predicate for you to make this
> even easier.
>
> catch $@->fatal => { ... }
That's nice syntactic sugar, and would simplify usage of RFC 88
facilities.
> > 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?
RFC 88 doesn't change the way die or eval work, unless you turn it on.
But if you want to use RFC 88 features, then you have to turn it on, and
then die becomes throw. So it does change the way die works. The
option to convert to throw and catch allows code formerly written to
misuse fatal error handling die/eval as non-fatal error handling to be
converted to use a new facility designed for non-fatal error handling,
leaving fatal error handling in peace.
> 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
By making throw/catch an orthogonal facility, whether it is turned on or
off, any traditional Perl code that misuses die/eval for non-fatal
errors will continue to work exactly as it currently does. I don't
think RFC 119 suffers from such a problem. However, when you turn RFC
88 on, it does: die no longer dies, it throws. Now that may not be a
problem for traditional Perl code using try.pm or error.pm modules, you
seem to have figured out how to stay compatible with those mechanisms,
but for people that have never dealt with those modules, and have always
handled return codes (because they could/should/needed to), vs just
simply allowing fatal errors to kill the program, the minute they turn
on RFC 88, they not only have a new mechanism for non-fatal errors, but
a new mechanism for fatal errors as well.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
