At 10:56 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >> Perhaps, throw can carry a return value?
> >>
> >> throw {"return value"} $exception;
> >> If there is an active try/catch context then the $exception would
> >> be propogated, otherwise $@ would get loaded with $exception and
> >> the return value would be the specified value.
> >>
> >> If not specified then it would be the same as a return with no
> >> arguments.
>
>PS> But what of RFC 70, which wants the option for exceptions in system calls
>PS> to cause program death?
>
>PS> Also I don't like code deciding to do something different depending on a
>PS> context that's possibly miles away.
>
>That would be a choice of the main program, Either wrap itself in a try.
>or a pragma that probably would look nicer.
>
>Actually, this would be no worse than any other perlian context. If
>the effect of a scalar context could make a remote literal ',' become
>a comma operator, than this can't be any worse.
>
>Another way to look at it, is that it _doesn't_ effect the callee. The
>callee wishes to terminate the function, and the next
>statement/expression will not be executed. The callee supplies the
>result. The caller is deciding how the results will be delivered.
>
>Hmm, I'm sure that some authors who like the error return style would
>like the pragma to force return context so that they don't have
>to wrap everything in a try.
Actually, there may not be a problem. RFC 70 merely calls for Fatal.pm to
have consistent and universal application. So if someone doesn't use it,
presumably all system calls return results instead, except for where they
have to throw an exception (and currently do), when RFC 80 comes into play.
--
Peter Scott
Pacific Systems Design Technologies
