Re^4: A question about method return values and error checking

The discussion was about concerns that return undef; in list context returns a list that is one element long, and thus true. In contrast, a bare return; in list context returns a zero-length result. This is a point that is lost on many acolytes. return undef; might bite you if you naively did something like:

my @names = $os->name( long => 1 ) or next; # No names
[download]

On the other hand, of you did

my @names = map $_->name( long => 1 ), @oses;
[download]

you would end up with lists of different lengths with the bare return;. Your solution puts the list elements back in scalar context, and thus avoids the actual question.

Update: I remembered where it really bites people:

my %hash = (name    => $os->name( long => 1 ),
            version => $os->version,
    );
[download]

where the mismatch has now resulted in a transposition of keys and values.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Comment on Re^4: A question about method return values and error checking Select or Download Code

Replies are listed 'Best First'.
Re^5: A question about method return values and error checking (unnatural) by tye (Sage) on Nov 05, 2015 at 16:03 UTC
`my @names = $os->name( long => 1 ) or next;` [download] That seems more like a strawman to me. I just haven't run into code where people do list assignments in boolean context when using a sub that just returns a single scalar. It is an unnatural construct. While using a scalar-returning sub as part of some list is done very often. So subs that never return more than 1 scalar should never use `return;`. Subs that clearly return a list should avoid using `return undef;` to indicate failure. - tye	[reply] [d/l] [select]
Re^6: A question about method return values and error checking (unnatural) by kennethk (Abbot) on Nov 05, 2015 at 21:10 UTC
I concur that it's a poor example, but I'm a bit pressed to come up with a good example to demonstrate why it's good practice. Ultimately, I think we agree on what good form should probably be. Maybe if I mull it for a while, I can come up with a better justification. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply]
Re^7: A question about method return values and error checking (unnatural) by Anonymous Monk on Nov 06, 2015 at 11:15 UTC
Decisions in interface design can sometimes have far-reaching consequences. The class of errors where values get injected, omitted or mixed up is typically more disruptive than a case of a missing value. To sum it up: where there's a method to fetch a single item, it is probably a good idea to return one item precisely.	[reply]
Re^5: A question about method return values and error checking by dsheroh (Monsignor) on Nov 06, 2015 at 11:03 UTC
Yes, agreed. I misunderstood your earlier reply to me as having been concerned about the lack of default placeholder strings on failure rather than with what it does to the structure of lists with positional dependencies (such as hashes and `printf` arguments). Fortunately, the solution presented in my previous reply resolves both of these issues.	[reply] [d/l]