Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

How to identify incorrect subroutine calls in a perl program

by Anonymous Monk
on May 15, 2006 at 17:25 UTC ( #549550=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Monks,
Caller.pl: use strict; use test; if (a != b) { est::Log("There is an issue") }
In the above sample code, I misspelled the call to the Log function in the test module and I couldn't figure that out during design time. I know I am using "strict" but it looks like it is not working. Is there a module that could help me to identify the invalid function calls during design time rather than run time. Thanks for your help Kris

Comment on How to identify incorrect subroutine calls in a perl program
Download Code
Re: How to identify incorrect subroutine calls in a perl program
by Fletch (Chancellor) on May 15, 2006 at 17:29 UTC

    You can't really. Perl being as dynamic as it is, there's nothing to prevent a subroutine Log in the package est being defined at run-time that it could know of by static analysis.

      Hello My apologies, I dont think the question I asked was what I intended to ask. The issue is, instead of saying "test::Log" in the code, I said, "est::Log". So you think there is no perl module that could help me to figure out whether the "est::Log" (where there is no "est" module) is valid or not, when I say "perl -c caller.pl" ? Please advise

        You can't tell if it's invalid; at best you could say that it might be invalid.

        if( $phase_of_moon eq 'gibbous' or $customer_account->balance > 867_5309 ) { eval qq{package est; sub Log { print LOG "Awooooooo: ", @_ }}; }

        Is it valid now? If you looked at the symbol table, you'd think no. But will it be valid the next time the program's run? How about the 2034th time you run it?

        Granted you possibly could write something to grobble over the parse tree and compare that with defined subs from the symbol table and then warns for things it doesn't see there. I don't know of anything that does that offhand though.

        And really I don't know if there'd be much call for it. Presumably you hit this error once, corrected it, and moved on. Just like any other run-time error in your code; the only difference from more conventional syntax errors is that you hit it at runtime rather than at perl -wc foo.plx time. Such is the price you pay for flexibility.

        Update: And the unit testing aficionados would chime in that you of course have tests which exercise all of the paths through your code so something would hit the offending code right out of the gate. :)

        Update: Added something to "Granted ..." to hopefully clear up wording.

Re: How to identify incorrect subroutine calls in a perl program
by dragonchild (Archbishop) on May 15, 2006 at 18:01 UTC
    Don't do things like that. You're bypassing the features built-in with strict. Instead of using test::Log(), have test export the Log() function. Then, strict will complain about a bareword, indicating the subroutine isn't defined.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      >perl -c -we "use strict; Log('There is an issue')" -e syntax OK

      What complaint about a bareword?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://549550]
Approved by Paladin
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-04-17 09:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (443 votes), past polls