There are several reasons why undefined functions are not caught at compile time, here are a few:

Autoloading
See AUTOLOAD in the perlsub document.

Conditional calling of functions

sub test {
  my $object = shift;
  $object->somefunction if $object->can('somefunction');
}
[download]

This is useful when you might have different objects being used that conform to a common interface, but have some additional capabilities.

Also useful when you might be dealing with older versions of a module that do not support certain methods.

Checking if an object can do something is generally preferrable to checking if an object is something

Actually there is one very reliable way to detect these situations - a comprehensive test suite.

Your test suite should have a test (or several) written for each of the cases that should cause a failure. If this test suite was run before each release you would catch the error that this post references.

Writing a compehensive set of tests can be an intimidating task, but the amount of time it will save you in the long run is well worth it.

Here is an article describing perl best practices, it has 10 tips from Damian Conway's excellent Perl Best Practices book.

I can't claim the test suite was comphrensive since it obviously wasn't. I've added a case that will cause the branch in question to be taken. I'll take a look at he article you referenced, thanks.

Run-time loaded functions and run-time generated function calls form the minority of functions and calls. A tool that can't handle those exceptions might exist and would still be valuable.

You could do an analysis of the output from perl -MO=Xref yourfile.pl. If there is a subroutine listed in the "Subroutine (main), Package main" section that's not listed in the "Subroutine definitions, Package main" section, that's a possible problem to look into. The same goes for other packages too. I'm just theorizing here, as I'm not fully up to speed on B::Xref, but it does look like a good place to start if you simply wish to check to see if subroutines being used match subroutines actually defined.

This doesn't get you very far with object method calls though. ...I guess that's what comprehensive test suites are for. ;)

#!/usr/bin/perl -w
use strict;

_undef_subroutine();
warn "Got here\n";
[download]

Undefined subroutine &main::_undef_subroutine called at C:\temp\undef.
+pl line 4.
[download]

Are you talking about a checking the syntax without running the script? Komodo has decent syntax checking but I am not sure exactly what you are looking for.

Did you write any tests for your code? If you had it probalbly would have shown up there.

Perhaps you need Symbol::Approx::Sub :-)

We have a universal AUTOLOAD function in our app which catches these errors and prints a nice message. I'm at home, so I don't have the code in front of me, but I remember that I got the idea from the perl cookbook. I just found the table of contents on O'Reilly's site: it looks like chapter 10.15 is what I'm thinking of.

We've had our AUTOLOAD for several years, and it does a few nice things besides catching our sloppy mistakes. However, it has a lot of disadvantages, like killing inheritance (which never used to bother us because none of our code was OO), and encouraging sloppy programming, so it's a mixed blessing.

-Joe

I wonder if PPI can distinguish between a subroutine definition and a subroutine call. If so, surely Perl::Critic can be made to look for subroutines that are called but never defined. Of course, this will give lots of false positives under certain circumstances, but it would still be better to have the option to check for such things.

Could B::Lint catch these? It does have an option for undefined_subs, so it may be worth a try.

Also, remember what was said by (I believe) Dijkstra: "Program testing can be used to show the presence of bugs, but never to show their absence!"

In other words, don't rely on testing to the exclusion of code reviews, verification tools, etc.