develooper Front page | perl.perl5.porters | Postings from June 2015

Re: Question/suggestion on perlfunc.pod example

Thread Previous | Thread Next
From:
Eric Brine
Date:
June 23, 2015 02:12
Subject:
Re: Question/suggestion on perlfunc.pod example
Message ID:
CALJW-qEp0KuTS_Q6EU+3Rzc8Uk6BmJEHMaEZo3WycBUF=7USCQ@mail.gmail.com
On Mon, Jun 22, 2015 at 2:13 AM, Aristotle Pagaltzis <pagaltzis@gmx.de>
wrote:

> Hi Eric,
>
> * Eric Brine <ikegami@adaelis.com> [2015-06-22 07:05]:
> > * Aristotle Pagaltzis <pagaltzis@gmx.de> [2015-06-21 08:15]:
> > > * Eric Brine <ikegami@adaelis.com> [2015-06-21 07:30]:
> > > > Under the usage pattern you now recommend, buggy code will instead
> > > > fail silently. That's bad.
> > >
> > > No it won’t. It will fail to distinguish the source of the error,
> > > and you have demonstrated this (redundantly, after I proposed to
> > > point out this lack of reliability in the docs), but it will never
> > > fail silently for failures of `do`, which you are welcome to try to
> > > disprove.
> >
> > I didn't say "for failures of `do`". Both the old and new handle
> > failures of "do" just fine.
>
> Then what’s the problem?
>

Showing people how to identify if do failed. The only way that's possible
is if the script can't return undef. You removed that.


> They vary how they handle other failures. The current boilerplate
> > displays the wrong error message at worse.
>
> The current boilerplate shows a use of `do` to read configuration, so it
> is very likely that the value returned must be a hash reference, but the
> code shown in the documentation never checks that. Isn’t that hiding an
> error?
>

Sure, but far out of scope. This is about reporting whether do failed or
not, and the only that's possible is if undef can't be returned. That used
to be checked. You removed that check.

I’m sure you understand that this would be silly


Need more straw? it would be silly, which is why I didn't bring up anything
of the kind.


>  not all users of `do` expect a hash reference


But all users of `do` that expect to be able to get an error message from
`do`, which is what we're showing how to do, can't return undef.


> > Current boilerplate:
> >
> > The file can't be executed: The error in $! is displayed.
> > The code in the file throws an exception: The exception is displayed.
> > The code in the file erroneously returns undef: A proper error is
> displayed
> > or the error in $! is displayed. XXX
> >
> > Suggested boilerplate:
> >
> > The file can't be executed: The error in $! is displayed.
> > The code in the file throws an exception: The exception is displayed.
> > The code in the file erroneously returns undef: Nothing is displayed or
> the
> > error in $! is displayed XXX.
>
> s/erroneously /ambiguously /, s/A proper/An/
>
> There is nothing inherently erroneous about returning undef


Yes, there is. It prevents errors from being detected and reported
correctly.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About