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

Re: Question/suggestion on perlfunc.pod example

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
June 22, 2015 06:13
Subject:
Re: Question/suggestion on perlfunc.pod example
Message ID:
20150622061339.GA77204@plasmasturm.org
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?

> 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?

OK, so then let’s add a check for a hash reference. Now notice what has
happened: we don’t even need to check for a defined value. An undefined
value is not a hash reference so it’s an error. And a defined but false
value is not a hash reference either, so it too is an error that will be
caught in the same single check. And there are even lots of true values
that are not hash references either, so it would be a waste of time to
check for a true value first; all those errors too will be caught just
by checking for a hash reference.

So clearly the example should contain a check for a hash reference, not
a check for a true value. After all, if the example doesn’t check for
a hash reference here, it is hiding an error. And if it does check for
a hash reference, then checking for truth is a waste of time.

I’m sure you understand that this would be silly: not all users of `do`
expect a hash reference, so the example should not include checks for
things that are relevant only to some particular users but not others.
Me, maybe I want a code reference instead. You, maybe you want a string.
Someone else, maybe they want a list (not even a reference) (yes, that
can be returned too) (but that suffers a semi-predicate problem in the
case of one single undefined element, so they probably ought to prefer
an array ref).

But checking for almost all of these things makes checking for a true
value a waste of time, because for almost all of these things, there are
plenty of true values that will not suffice. So why should we give the
user boilerplate that checks for things that are a waste of time to
check for and in some rare cases may not even be applicable (e.g. for
users who don’t mind defined but false values)?

So after all this, you ought to be able to see that this statement of
yours:

> The new boilerplate can hide an error message.

… is nonsensical, because giving boilerplate that applies to everyone
does not and cannot prevent the user from adding user-specific error
checks after the given code, which s/he has to do anyway, because the
boilerplate can never include error checks for user-specific conditions.

> 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; it’s just
not a smart value to expect, because expecting it instead of something
else makes it overly easy for whoever writes the included file to write
it in such a way that it accidentally signals an error.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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