I have to agree with extremely here. You are testing downstream of where the problem really is.

When deciding questions like this, I like to focus on "What is the set of values that my function (expression, test, ... ) should accept?". After determining this, I write the function to handle those cases. I *want* to get warnings when values outside of my expected input set are given to my function. I even might code some calls to die() just to make sure I will notice when this happens.

In the example above, I would thus recommend to make sure some_sub() returns a value that makes sense to the rest of the program (e.g., only numeric values).

This line of reasoning may seem problematic if you think of generic routines, e.g., dispatching code that uses dynamic handler tables. It is not. If you assume anything about the functions you want to dispatch to, or get return values from, you better make that assumption public, either by encapsulating your assumptions in an interface (e.g., an abstract data type with operations to handle input arguments and return values), or by documenting your assumptions (not the real thing, but better than nothing).

Turning off "-w" in production code "so I don't see that pesky warnings stuff" (the other "solution" to your problem) makes me extremely nervous. Generally, if people argue like that, there will be problems. Tip: turning "-w" on in big applications that have it turned off often makes for interesting reading and hours of insight and fun.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com