Re: Draft 2 of RFC 88 version 2.

At 11:03 AM 8/21/00 -0400, Chaim Frenkel wrote:
>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.

We can try to simplify them.  Unfortunately my part will have to wait until 
tomorrow, I must hie imminently.

>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.

This is between you and the module author.  Even if we could dictate this 
to them, it would be outside the scope of this RFC.

In Java, the interface to a method specifies what exceptions it can throw, 
and it is an error for it to try to throw anything else.  So it's very easy 
for the user to know what they should trap.  A Perl module, though, will 
have to document what exceptions it can throw.

>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_.

Well, you could certainly have a pragma that makes throw set $! to the 
message and does a return undef.  But that will only return from the 
current subroutine; there could be a bunch of module subroutines between 
that one and the module user.  Asking module programmers to keep straight 
two possible flows of control in error situations, no less, is asking for 
trouble.  If you think it can be made easier, can you show an example?

I think all we can do is encourage module authors to provide both styles 
with a switch to select them by (API decided by module author).  The 
reality will be that some module authors will do that, some will do 
exception handling everyhere, some will do error return everywhere, and 
some will do a mixture of both in the same module.  Which, btw, is what we 
have right now.  Grep the core pm's for 'croak' and 'die'.  Take a look at 
the (F)s in perldiag.  Notice that division doen't return undef when the 
dividend is 0 :-)

>(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.))

Exactly :-(
--
Peter Scott
Pacific Systems Design Technologies