Those rule are hard to read. I've tried reading them quite a few times
and I have trouble understanding them. I can't tell if the rules are
complex or it simply needs to be reworked. If it is complex then I
don't think this is the right approach. The rules should be simple.
As for legacy. I strongly urge that Modules _never_ die. It is extremely
rude. The fact that something went wrong, doesn't mean that my 100 hour
complex calcuation should be terminated. The fact that I couldn't send
an email message may or may not be of importance in the scheme of things.
And if throw becomes the standard, then you are forcing _all_ programs
to accept exception handling.
Isugest that throw should be convertible into an effective return
(with appropriate setting of $!) upon the (pragmatic) request of the
_caller_.
(I realize that this may not be possible, but I'd like to have it
kept as a possiblity. The call stack between the thrower and the
catcher (where the catcher may have pragmatically asked for return
style and the intermidiaries may or many not have even thougth about
the problem.))
<chaim>
>>>>> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Perl's behaviour after a C<die> starts call-stack unwinding, as
TO> envisioned by this RFC, is as described by the following rules.
TO> 1. Whenever an exception is raised Perl looks for an enclosing
TO> try/catch/finally block.
TO> If such a block is found Perl traps the exception and proceeds
TO> as per rule 2, otherwise program shutdown is initiated.
<snip>
TO> Legacy
TO> It is not the intent of this RFC to interfer with traditional
TO> Perl scripts; the intent is only to facilitate the availability
TO> of a more controllable, pragmatic, and yet robust mechanism when
TO> such is found to be appropriate.
TO> Nothing in this RFC impacts the tradition of simple Perl scripts.
TO> C<die "Foo";> continues to work as before.
TO> There is no need to use try, catch, or finally, and most of the
TO> cases where you would want you use them takes less source code
TO> with exceptions than with return code checking, as per the
TO> CONVERSION section above.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
