“Fair warning” here ...

I advise that you should not write code which depends on the “truth value” of whatever-it-is that a subroutine or expression might yield.   If you expect that a sub will return, say, “an empty string,” or “an integer 1 or 0,” or “undef” or what-have-you, test specifically for that.

And if you don't get anything you expect, (use Carp and) croak in a meaningful way.

“Put debugging tests into your program and leave them in until you’re absolutely sure that every last bug is gone.   Then, and only then ... leave them in.”

Sure, there are well-understood exceptions to that advice which we find everywhere in the language-of-use, such as the ... or die construct.   Such things are so well-known and widely accepted that they are probably just fine.   But the party that is always in the very best position to discover an error in a computer program is ... that computer program itself.   Within reason, the more that program(mer) takes the “I’m From Missouri... Show Me™” point of view, the more rugged and reliable his or her code turns out to be when it moves into production.