in reply to How to initialize all variables

Find and solve the root problem.   Don’t patch mere symptoms.

If the script “is run on many other servers without this problem,” then the root problem, which you must find and understand, is:   “what is making this server environment different?”

Problems like these are bellwethers.   They reveal the existence of a problem, doing so in an easily visible way.   If you “merely mask” them, the problem does not go away.   It only becomes vastly more difficult to spot, and the application remains unstable.   As you continue to thrash away at it, as you will, client confidence erodes.

Replies are listed 'Best First'.
Re^2: How to initialize all variables
by roboticus (Chancellor) on Sep 12, 2010 at 14:06 UTC

    sundialsvc4:

    This is another one of those nodes where I wish I could click the ++ button a few more times. It's easily the best response to the OP that I've read so far.

    ...roboticus

[reply]
Re^2: How to initialize all variables
by shawnhcorey (Friar) on Sep 12, 2010 at 15:01 UTC

    What about those cases were you can't change the root of the problem? I've worked in shops where getting approval for something like XML::Simple is a three-year process. What do you do in the mean time while your changes to the web server are waiting to be approved?

    Initialize all your variables whenever they need it; don't assume the system will do it for you.

[reply]

      As we all very well know, “software configuration management” (that onerous approvals-process) really is a critical thing.   We cannot edge around it, and we really do not want to.   Nor should we have to.   If there is a defect in the code, then it is probably in the code:   in the code that your team has written; not in what made it to CPAN.   (Which code also made it through Test::Harness as a precondition to being successfully installed on your computer in the first place.)

      “Root causes” are typically architectural, and as such they are often very expensive to fix.   They are like foundation problems on a house ... or worse.   But I also think that one of the worst “root causes” arise from the change process itself.   Someone finds a bug and, with or without documenting the change, “makes it go away.”   Trouble is, the problem only “goes away” symptomatically.   The underlying issue often remains ... concealed, un-addressed, and now even more thoroughly wrapped up in obfuscation than it ever was before.

      Hence, you really have no choice but to dig down and find out why this thing is breaking.   Consider yourself very lucky, in fact, that the “incorrect value” that you are dealing with happens to be undef.   Perl knows how to die when a variable contains this particular value.   It won’t say a word, though, if a “2” is really supposed to be a “3,” even though this would merely be yet-another manifestation of exactly the same underlying problem...

      Best advice?   Learn as much as you can about automated software testing, i.e. Test::Harness and all of its kin.   The stuff that you see CPAN doing, every single time you install or update something.   All of the source-code for how CPAN does this is right there.   The tools are well-developed and very refined.   Even if you begin only by creating test-suites for your most simple and foundational code, you will be amazed (as I certainly was) at what it turns up.   It is seriously like having the waters of the lake upon which you are confidently traveling ... getting ready for another release ... suddenly turned clear, and all around you, directly in front of you, are thousands of obstacles, land-mines, sharks, what-have-you ... every one waiting to be “discovered” and in the very worst possible way.   You obviously cannot finish this kind of thing, “ex post facto,” but you can surely start, and any-and-all progress that you make in this direction will be a massive step in the right direction.

      Then you put it in writing that the work-around will be fragile, may make other bugs harder to find and fix, and will lead to much greater expense in the future and perhaps more serious bugs.
[reply]

In Section Seekers of Perl Wisdom