Re: Functions that return nothing, nada, failure...

So if return; is just as right as return ();, but twice as fast, when would you use return();?

I vaguely remember the meme "use return with no arguments to return false to any context" as received wisdom, but I can't find any such citation.

I would argue that it is sufficiently common usage that it should probably be the default way to signal "false" unless you have good reason otherwise.

If you find yourself in the situation where there are no valid sentinel values to indicate "false" (perhaps you are returning a list where the empty list might be a perfectly valid response) then you need to signal failure some other way. Three come immediately to mind:

Exceptions. This is my preferred technique.
Extra return values. Ugly, but since perl allows for multiple return values, this is workable. (A related technique is passing in a reference to a status variable.)
Global variables. Also ugly. Think errno in C (and how its use forced the rewriting of many calls to make them reentrant, by using the "pass status variable by reference" technique.)

In my own code, I can mostly get away with dealing with empty lists as a normal occurance; if I don't get any answers back, then I just don't do anything. Relying on foreach, map, etc, and avoiding keeping any meta-data about these collections in other variables makes this style straightforward and easy to read.

Exceptions let me write most of my code without worrying about the corner cases; I catch those exceptions towards the top of my code, where I have large chunks of work that I can either accept or reject ("commit" or "rollback", if you like.)

(One thing I would love is if the Fatals module would create detailed exception objects for every call mentioned; currently it is a bit cumbersome to customize the details for each case, so I still have ... or die "..." chunks throughout my code.)

Comment on Re: Functions that return nothing, nada, failure... Select or Download Code

Replies are listed 'Best First'.
Re: Re: Functions that return nothing, nada, failure... by adrianh (Chancellor) on Jun 01, 2004 at 10:54 UTC
I vaguely remember the meme "use return with no arguments to return false to any context" as received wisdom, but I can't find any such citation. From `perldoc -f return`: If no EXPR is given, returns an empty list in list context, the undefined value in scalar context, and (of course) nothing at all in a void context. :-)	[reply] [d/l]
Re^3: Functions that return nothing, nada, failure... by tkil (Monk) on Jun 01, 2004 at 20:03 UTC
[snarky quote from perlfunc omitted] Ha ha. :) Unfortunately, it's not clear that this is an endorsement of using the naked `return` to signal false or failure: it is only a statement that it will, in fact, return something which will be interpreted as false by perl in whatever context it is called from. The question at hand, though, is whether there is any argument (either from authority or from a rational basis) for declaring the naked `return` as the "best" way to return false. At the least, I would argue that using it fits the principle of least surprise. (I wouldn't want to have a list that explicitly returns `undef` suddenly be interpreted as "true" just because I changed the context I was returning it into.) I actively dislike the solutions recommended so far (always return either `undef` or `()`, and then document it). Unless there is a very specific reason to do otherwise, I would prefer that people just use the naked `return` and let the calling context figure out what to do with it.	[reply] [d/l] [select]