Peter Scott wrote:
>
> Now, I do not want that to detract completely from Chaim's point,
> which is well taken. I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename }
> catch { die "Couldn't copy source: ", $@->syserr }
>
> I *know* that it sucks, linguistically, to convolve error
> notification with the return data space, and then to pass
> additional information out-of-band in a global variable. It also
> happens to be darn readable. I don't want to give it up any more
> than you, Chaim.
On this matter I believe we are all in agreement. The behaviour
of open should be under the control of C<use fatal;>, and traditional
Perl code should continue to work as, well, traditionally.
> I think I have an answer. We should be able to take care of the
> core by using Fatal.pm; so if a program wants core functions to
> set $! and return anyway, that will be the default. This means
> that some core functions that currently die will need their
> interfaces reworked.
Agreed. C<no fatal;> is the default.
If deleted the following from RFC 88 + IMPACT + RFC 70
The author of RFC 88 is of the opinion that Perl 6 should bite
the bullet and just go with exceptions for internal faults, but
he would be happy with a robust C<use fatal;>, should that
approach be taken.
I've added the following to RFC 88 + ISSUES + Core Functionality
The authors are of the opinion that the public interface to
to the core Perl API should support but not require the use
of exceptions for errors, under the control of a C<use fatal;>
or C<use strict 'fatal';> pragma.
> I actually see nothing wrong in division returning undef for a
> dividend of 0. It's just as easy to check as doing an eval.
Please don't do this. I would have to check every divide in all
my code, since no fatal is the default! Leave the current version
of Perl's best guess as to what it should die on alone, unless
use fatal is in scope. Consider this:
$amount_i_owe_you = $gross_amount / $discount_rate - $paid;
If $discount_rate is accidentally undef and $paid is $100, then the
$amount_i_owe_you is now -$100. I don't see my cheque yet ;-)
> Module authors should also be able to take advantage of Fatal.pm.
> "use Fatal" should set something that can be checked by any
> programmer (heck, that doesn't even have to be restricted to
> module authors; the creator of an insanely large program might do
> it). The programmer can use this to decide whether to throw an
> exception or return.
That's what I meant by $FATAL_MODE in my previous message.
Yours, &c, Tony Olekshy
