My personal favourite, and I suspect the best answer in this situation, return just return the list by reference.Īnyway, I suspect that's something like what you want.
#ROSE DB TEXT FIELD OF 0 RETURNS UNDEF CODE#
Very clean as you don't have to test for errors everywhere, but if you don't want to be eval/try'ing all the time, or the 'policy' for the code doesn't not allow to use exceptions everywhere, this can get nasty. You might use formal exceptions, but they just die underneath. Secondly, we get the exception method, which in perl is essentially "die"ing with the error message. And what if a single undef element is a legal return value? You also get similar problems when you 'return undef', as undef returns in list context as a single element array with an undef in it, which is probably not what you REALLY want anyways. you only get the number anyways and not the list In list form, () = error, which can suck when you legally return a null array. This is the simplest, but when you want to also signal an error, suffers from tricky testing. The original way is to return the data as a list (returning an array does this), and for the error case just 'return', gives you 'false' in both list and scalar context, the null array in the case of a list context, and undef in scalar context. There are three reasonably cohesive ways to return a list, depending on what you are doing one of them should be relevant. Perl is filled with people offering the best way to do things, often correctly, and sometimes totally not what you expect.īut since variety is the spice of life. This and more wisdom available from Markov Hardburn. Send money to your kernel via the boot loader. &mysub2(mysub1) invokes mysub2 with the text 'mysub1' so is not empy. WhenI looked at your code, I wondered that you didn't have parentheses when you call mysub1, but it slipped past me all the same, until I did what you should have done, run the code in the debugger. It's pretty clear to me what the OP expected, and where the OP went wrong. Both the comment and the code show that the OP expected to be empty. The OP may have meant that the sub returns a list of whatevers, or he might have meant that it returns an array reference. The fact that a list element can be a reference to an array is an interesting observation in its own right - but not for this discussion. The whole problem of the OP deals with the fact subs return lists, not arrays. That's like responding to someone who says "you can't make trees with a camera, just pictures" with "but you can make a picture of a tree!". Thought into how it returns, but that's only a split//,".rekcah lreP rehtona tsuJ" $\=$ ->() printĪ sub never returns an array _directly_, but it can return arrays by reference, along with anything else it wants to return, in its list of return values. The non-error case yet and hasn't put a lot of That case and focused on the error case where he He only gave us a possibly-misleading comment for Of whatevers, or he might have meant that it returnsĪn array reference. The OP may have meant that the sub returns a list It wants to return, in its list of return values. Return arrays by reference, along with anything else They return lists.Ī sub never returns an array _directly_, but it can This is done especially to help in cases you are using.
In scalar context, that will return an undefined value - in list context, it will return an empty list. What is special cased is return, that is, a return without arguments. It's not any different from return "feebleprops". If you assign it to an array, you get an array with one element, that element being undef. If you assign that to a scalar, the scalar will have the undefined value. Return undef a list of one element is returned. "Efficiency is intelligent laziness." -David Dunham
0 kommentar(er)
