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

I was wondering if anyone has a good explanation for the following strange behaviour:

I have the following module. 

#REMEBERED TO CHANGE THE MODULE NAME HERE
use Module::With::New::PackageName;


sub generate{

  #open a temp file.

  my $workbook = Spreadsheet::WriteExcel->new( $filehandle );

  #PROGRAM DOES NOT REACH THIS POINT!

  write_form( ... );

  #close the sheet.

  #open the temp file and return the content as a string.

}

sub write_form{

  #do something

  #FORGOT TO REPLACE NAME HERE
  Module::With::Old::PackageName::perform_action();

  #do some more
}

[download]

The code above worked fine before I changed the package name of a package that was used in the function write_form. After I changed the name of the module from Module::With::Old::PackageName to Module::With::New::PackageName, the program never managed to finish the execution of Spreadsheet::WriteExcel->new. Perl did not produce any error messages or warnings, it just stopped executing.

Correcting the package name in write_form fixed the problem, but I can't see the connection between the wrong package name and the error that it caused. Shouldn't Perl give me an error message when the execution reaches the wrong package name and not in some unrelated function?

By the way the application where this code is located is a web application that is created using CGI::Application, running on an IIS server with ActiveState Perl 5.8.7.

2006-10-17 Retitled by GrandFather, as per Monastery guidelines
Original title: 'Any explanations for this bug?'

Replies are listed 'Best First'.
Re: silent failure with non-existant module
by imp (Priest) on Oct 17, 2006 at 13:49 UTC
    Always use strict.
    Always use warnings.
    Avoid using explicit package names in code, instead have the other package export the function in question.
    Also, please use meaningful titles for future posts. See How (Not) To Ask A Question
[reply]

      use strict and use warnings was used in the module, but it did not catch the error. Perl did not warn be in any way, it just stopped executing at an unrelated place.

      Can't exporting functions lead to problems with more than one function having the same name? This code is part of program that already is quite large.

      Sorry about the title. Forgot to change it when I read through the post.

[reply]
        Perl will die with an error if a method that does not exist is called, unless there is an AUTOLOAD method.

        Note that dying will not result in output to stderr or the program terminating if it is contained in an eval block. Perhaps this is happening in your case?

        For more help we will need a bit more code to work with, but please keep it to the minimum working implementation that demonstrates the error. Reduce it to the simplest form that still behaves in the undesired way and you will usually find the problem, otherwise post it here.

[reply]
Re: silent failure with non-existant module
by kwaping (Priest) on Oct 17, 2006 at 14:42 UTC
    Where does $filehandle come from, in your generate sub?

    ---
    It's all fine and dandy until someone has to look at the code.
[reply]
[d/l]
[select]

      The filehandle is created using File::Temp like this: 

      my $tmpdir = File::Spec->tmpdir();
my ($filehandle, $filename) = File::Temp::tempfile( "generated_XXXXXX"
+, DIR => $tmpdir, SUFFIX => '.xls', UNLINK => 1);
   
    confess "Error!" if !$filehandle;
    
    binmode $filehandle; #Spreadsheet::WriteExcel only worked with bin
+mode

      [download]
[reply]
[d/l]
        How does it get into that sub? Are you referring to it as a global, or do you pass it in as a parameter?

        I guess what I'm really getting at is that your example code might be a bit too stripped-down for us to accurately diagnose your issue. There appear to be quite a few significant gaps. Can you flesh out your example code a little more, or is that really your actual code?

        ---
        It's all fine and dandy until someone has to look at the code.
[reply]

Back to Seekers of Perl Wisdom