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.
But what of RFC 70, which wants the option for exceptions in system calls
to cause program death?
Also I don't like code deciding to do something different depending on a
context that's possibly miles away.
><chaim>
>
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
> >> One issue that haven't seen addressed, is how to _not_ have exceptions.
> >>
> >> I want to use a core module (non-core can do anything they want) but
> >> I'd like to write it in procedural mode.
> >>
> >> try {
> >> $obj->method...
> >> }
> >> catch { }
> >> finally {}
> >>
> >> or
> >>
> >> $status = $obj->method...
> >>
> >> And have both work properly.
>
>PS> Yes, I want this too. The method could certainly look to see whether
>it's
>PS> in void context and throw an exception if so; in fact Jarkko suggested
>this
>PS> just now on p5p:
>
> >> Mental note: in Perl 6 system calls by default should die if their
> >> return value isn't checked.
>
>PS> Short of setting some global switch, I don't see how else to do
>PS> it. However, this doesn't address the issue of functions which return
>PS> values anyway and signal errors through $!. If we get open() modified
>as I
>PS> and others would like:
>
>PS> my $fh = open $filename;
>
>PS> how should we distinguish the one that throw()s from the one that doesn't?
--
Peter Scott
Pacific Systems Design Technologies
