develooper Front page | perl.perl5.porters | Postings from September 2012

Re: Changing the Perl error message when a module is not found

Thread Previous | Thread Next
Aristotle Pagaltzis
September 17, 2012 23:57
Re: Changing the Perl error message when a module is not found
Message ID:
I think this error message should be a model:

 $ perl -e'Foo->bar'
 Can't locate object method "bar" via package "Foo" (perhaps you forgot to load "Foo"?) at -e line 1.

Applied in this case that would be something like this:

 Can't locate LWP/ in @INC (perhaps you forgot to install "LWP::UserAgent"?) (@INC contains: /etc/perl /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 /usr/local/lib/site_perl .) at -e line 1.

That also seems to me to insert the advice in such a way as to break the
least amount of code dependent on the format of this error.

It’s not a great error message, but I don’t think much better can be
done in light of the legacy.

* David Golden <> [2012-09-16 22:25]:
> I support changing the error to have the module name -- but I'm not
> sure if that's technically possible as I think the module name might
> be converted to a path during compilation and then you can't reverse
> any relative path at runtime because someone might actually call C<<
> require 'Foo/' >> and it wouldn't be right to say "could not
> load Foo::Bar" in that case.

The “maybe” formulation covers this, doesn’t it? Even if the code says

    require 'Foo/';

it is still applicable to ask “perhaps you forgot to install Foo::Bar?”
when that fails because the form the code uses to load is irrelevant to
the fact that the user doesn’t have the module installed, if that is in
fact the problem. So blindly translating the path back into a package
name seems to me to be fine.

* demerphq <> [2012-09-17 12:35]:
> So then this is an XY problem right?
> You are asking us to change the error message (X) in an attempt to
> work around the problem that newbies don't use diagnostics (Y).
> But instead you should be asking how we can solve Y, which is "how do
> we make sure that newbies know about and use diagnostics".

Totally and completely disagree. The usability of a programming language
is overwhelmingly dependent on the quality of its error messages. (Have
you seen the lengths to which Larry goes for them in Perl 6? It deserves

Turning on diagnostics should be verbose mode for error messages – not
be required to make errors actually name the *actual* problem, rather
than speak only in terms of how it expresses itself. Solving the problem
should not start with a Sherlock Holmes plot to deduce what triggers the
error message.

Don’t forget that the audience for these error message does not include
only programmers, but also users of code who may not know or even care
it is written in Perl. They are the ones most baffled by it, and making
*them* learn how to turn on diagnostics in order to get error messages
that get straight to the point is… not even wrong.

* Vadim Konovalov <> [2012-09-17 09:30]:
> I dislike this advice, because this guess is correct in some 90% cases
> but is wrong in other 10%, and dealing with error in these 10% becomes
> harder.

I think my suggestion addresses this.

* Eric Brine <> [2012-09-18 08:05]:
> The use of "try" indicates uncertainty, a possibility of failure.
> That's the very opposite of a complete list.

“Try X” does come off very optimistic that X is the correct solution
though. I would hardly say the opposite, much less the very opposite…
though it does leave room for X not being the solution.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About