Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Error reporting in Function::Parameters

by golux (Chaplain)
on May 31, 2018 at 18:08 UTC ( #1215557=perlquestion: print w/replies, xml ) Need Help??

golux has asked for the wisdom of the Perl Monks concerning the following question:

After getting tired of Method::Signatures often reporting the wrong error line, I turned to Function::Parameters, having read somewhere that it didn't have this problem. However, the issues I'm having with Function::Parameters are often worse. When used in conjunction with Moo, the first line where the error occurs is often reported after numerous other lines are reported first, making the root cause hard to find.

Worse, the error reported may have nothing to do with the actual error!

Consider the following module "":

package Thing; use Moo; has topdir => ( is => 'rw', required => 1, ); use strict; use warnings; use Function::Parameters; # Methods method loop() { while (1) { my $val = rand(100); if ($val > 80) { # Do nothing if value is over 80 nnext; # This line has the actual error } ($val < 20) and return $val; } } method getcwd() { my $cwd = $self->topdir; return $cwd; }

Running perl -c produces (at least for me) this error:

"my" variable $cwd masks earlier declaration in same statement at Thin line 31.
This error seems meaningless as it's not even in the method loop() where the error (the typo "nnext") actually occurs.

If the method getcwd() is changed to:

method getcwd() { return $self->topdir; }
suddenly the error is correctly reported:
perl -c Bareword "nnext" not allowed while "strict subs" in use at li +ne 21. syntax error at line 29, near ") {" Global symbol "$self" requires explicit package name at line +30. had compilation errors.

Note that my original module is almost 2,000 lines, and the error not at all obvious until I started making random changes to try to get Function::Parameters to reveal it.

Does anyone know why this would be the case? Should I be using a different module for type signatures (besides Method::Signatures and Function Parameters)? Or is there some workaround I'm unaware of?

say  substr+lc crypt(qw $i3 SI$),4,5

Replies are listed 'Best First'.
Re: Error reporting in Function::Parameters -- or by Moo?
by Discipulus (Abbot) on May 31, 2018 at 19:42 UTC
    Hello golux,

    If I'm permitted to do some wild guess, the problem you are facing does not rely within Method::Signatures nor Function::Parameters but with Moo on it's own.

    Moo does a lot of code generation and a syntax error makes everything go messy.

    Also compiletime/runtime timing must play a role in this: as you discovered perl -c reveals the right point where the error happens: 'Bareword "nnext" not allowed.. '

    I'd try to change use module into require module or using Module::Load as side experiment.

    I hope this can be useful for you even if my English is easily misunderstandable and my OO experience is very very limited.

    See also this Moo report


    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      The error reported doesn't change if use of Moo is removed from the code. Moo doesn't change how the rest of your code is parsed. This is definitely an issue in Function::Parameters. It seems to be getting confused about how to continue parsing after a compilation error.
Re: Error reporting in Function::Parameters
by (anonymized user) (Curate) on May 31, 2018 at 23:18 UTC
    The short answer is that any error can cause this behaviour in any piece of code. Parsers of just about any language often stop working after encountering a syntax error. It is pretty common for Perl to produce 'fake' errors afer a real one is encountered. This is because parsers rely on the programmer obeying the rules of the language to be able to continue parsing - it is just about impossible to write a parser that can figure out what the correct syntax should have been in order to carry on parsing correctly after the parsing error. It is true that the extra challenge of Moo might make it harder to see why such a fake error happened - it is probably because Moo forces an extra language layer into play. But it is better to presume that fake errors will appear in general after any real error and not worry about the particular circumstances.

    One world, one people

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1215557]
Approved by hippo
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2020-11-23 22:35 GMT
Find Nodes?
    Voting Booth?

    No recent polls found