in reply to Tracking down uninitialized values...

My experience is that once you get to the harder cases of uninitialized values, they are caused by variables where you stare at the it and think, "well that has to be there", and you later find out that it's not. The solution is to check each parameter at the entry to each function to see if it's defined, and kick off a warning or a die if it should be defined and isn't. It's tedious to write, and it interupts the flow when you're reading the code, but it saves lots of grief, IMO.

It's also useful to have those checks in there when something changes with the data and the routine blows up, 6 months down the road.

  • Comment on Re: Tracking down uninitialized values...

Replies are listed 'Best First'.
Re^2: Tracking down uninitialized values...
by Slipstream (Monk) on Jul 28, 2006 at 17:05 UTC
    Both good suggestions (the above and the higher up about finding that certain eval). It seems like if the problem ends up being in a module that's being called it would be MUCH more difficult to track down by putting checks in the local code unless I played the elimination game of removing lines until the problem goes away.

    I thought I had read the debugger had a mode that would basically allow me to step through the program and see what happens as it executes. I was hoping I could use something like that to watch for exactly where/what it was complaining about.

    Time to visit the friendly manual some more. ;)