in reply to CGI::Appl can't find sub

It seems likely that adding the subroutine call altered the scope of Asub2. Perhaps you deleted a closing curly brace or a semi-colon?

Are you using warnings and strict? What does perlcritic say? When you use perl-tidy, is Asub3 indented the way you think it should be?

If you aren't using these tools to analyze your problem, is there a reason for skipping them?

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

Replies are listed 'Best First'.
Re^2: CGI::Appl can't find sub
by jimt999 (Initiate) on Jun 11, 2014 at 15:30 UTC

    Thanks for the feedback. There are 4 perl modules with 3500 lines of code that I'm not familiar with. I have tried disabling various pieces, but there are many dependencies. I'll take another pass at minimizing the code.

    I am using strict and warning. I added "use B::lint". I also tried "perl -MO=Lint,all myprogram". Thanks for suggesting perlcritic. I wasn't aware of that. It did not turn up anything that seems significant with a warning level of 3. I might try a more detailed pass.

    Here is the single line, that when commented out everything works fine:

    my $ret2 = &CCC::DDD::setCAlist($self->param(CA_list));

    The subroutine it is in already had the following call just a few lines above the line I added and everything works fine.

    my $ret = &CCC::DDD::init($cfg_file,$repfp,0);

    I was hoping that someone had seen this exact error in a similar calling scenario or suggestions on additional tools and debug methods. I didn't expect a full analysis given only an outline. It seems like a syntax or scope issue in existing code, not a problem in that one line to call CC::DD::setCAlist(), but I am new to perl.

      I'm guessing that maybe init is a constructor returning an object. If it is then you should probably be calling setCAList as a method like this.

      my $ret2 = $ret->setCAList($self->param(CA_list));

        Good thought, but init() doesn't return an object. It is re-used later in the same routine for the return codes of other calls.

        As I experimented more, I got a non-working case that did not even have the call. *Update* I mis-typed and aded an error that was not flagged at compile or runtime. Removed the comment about the "if".