I would echo the sentiment that ... “this idea stinketh .. large.”   :-D

What I mean is ... sure ... TMTOWTDI™ ... but ... you will surely and sorely regret having done it that way.   (IMHO... YMMV.)

I have come to realize that the best way to handle failures is to throw an exception, either with die or with one of the Carp routines.   Arbitrarily complex code can now be surrounded by eval blocks, and, no matter exactly where-or-when the failure occurs within that block, it is caught and can be dealt with – as “the exception” that it really is.   (Otherwise, you wind up with code that sounds like that annoying cell-phone commercial in the US... constantly asking,   “can you hear me now?   can you hear me now?”)

In any case, I abhor the idea of returning a string in one case and a number in another.   Consider the idea of having a Perl class, which simply indicates success or failure in the initial call, and which then provides other methods to retrieve either the results or the error-information.   Although the idea may feel a little bit peculiar at first, I think it really works out well.   Even a simple package-variable can be used in simpler situations, with a package subroutine that retrieves the (otherwise hidden) variable’s value for you.