Chaim Frenkel wrote:
>
> You are being extreme here. I use perl _because_ it is so
> forgiving. I can easily do unlink("foo.err") and not check
> return codes because I don't care if it was there before.
No sir, I am not being extreme. Don't C<use fatal;> and don't use
try/throw/catch/finally, and
nothing I'm talking about changes
anything you are used to doing. I went to a large amount of trouble
to minimize the impact of RFC 88 on existing Perl 5 code; there is
almost none ($@ and @@ are now read-only and contain Exception
objects -- that is all). This is explained clearly three times in
RFC 88, once right in the ABSTRACT. I don't know what else I can say.
> Tony Olekshy wrote:
> >
> > > Chiam Frenkel wrote:
> > >
> > > 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.
> >
> > What would happen if the email module gets an overflow on a ++$i
> > (or anything else dies, no matter what it calls or does)?
> > Because you are ignoring possible problems with email (instead
> > of properly handling them by ignoring them [sic]), your 100 hour
> > calculation is toast even though the email didn't matter to you.
> > You just got lucky. You should have written (contents of catch
> > block optional):
> >
> > try { that_email_thing(); }
> > catch { print "Email not sent.\n$@\nContinuing anyway...\n"; }
>
> Still a staw man. The email is a nice feature. The log file might
> be the actual official result. Especially given the way the email
> is like at my client.
Sorry I wasn't more clear. My only point was that if you write:
that_email_thing(); # ignore failure returns.
then you are not correctly ignoring errors, because that_email_thing
may die due to an internal exception, even if it didn't intend to.
If that happens you'll die to, even though that's not your intention.
If you write:
eval { that_email_thing(); }; # ignore all failures.
then you are correctly ignoring errors no matter how they happen.
This is already the case in Perl 5; RFC 88 doesn't enter into it.
> > A major corrollory benefit of all this is that once people make
> > the transition to exception-based error handling, the
> > reliability of all software goes up, because you end up with
> > whole systems that are layered to cope with failure, instead of
> > whole systems that depend on no-one botching an else return $rc
> > or a ++$i, not even one.
>
> You are preparing to force all programmers to your way of thinking?
> This is not what perl is about.
I sir, am not forcing anyone to do anything. RFC 88 makes one thing
easier to do. "On the case for..." makes an argument that now that
it's so easy to do, maybe we should start doing it more, because
then we would get the benefits described in said essay.
> I DONT WANT TO BE FORCED TO USE YOUR STYLE SIMPLY
> TO USE THE MODULES IN CPAN OR THAT SHIP WITH PERL.
No need to shout.
Public APIs to core modules should respect the current state of
<use fatal;>, by using the following construct for error returns:
return $FATAL_MODE ? ERROR_IO : throw Error::IO;
What modules in CPAN do is none of my business. They can weigh
the pros and cons of both approaches, and select whichever is
appropriate. RFC 88 *only* makes one of those approaches easier
than it was in Perl 5. Nothing more.
I have probably written Perl code on at least half the days of
my life for the last 10 years. Much of that code has been one-
liners or simple scripts. I *don't* want to change how Perl
does those. Much of that code has been applications containing
hundreds of files. I want to change how easy Perl makes it to
do those well.
Your, &c, Tony Olekshy
