Yes. Previously my return statement was in a loop that "processed" the array. I didn't want to "process" an empty array. So if the array was empty I returned nil. However returning the empty array works fine (i.e. I took the return statement out of the conditional statement that protected the "processing" code. If that makes sense. At the time (well up until yesterday in fact) I was under the misguided impression that an empty array and a nil array were the same thing (superficially as least - the reality is I never reflected on the problem long enough to really consider it in those terms because in hindsight it appears obvious now).
Regardless I agree the lack of tools to deal with a nil array make it something to avoid. ~joe On 12/8/06 8:48 AM, "Norman Palardy" <[EMAIL PROTECTED]> wrote: > > On Dec 08, 2006, at 7:28 AM, JC wrote: > >> Yep. Returning the empty array works just fine. My comments were >> referring >> to the parsing of the array which I was trying to avoid. The return >> statement works just fine outside that conditional statement. >> >> ~joe > > Not an empty array; a NIL array > If you return nothing from a routine that declares itself to return > an array then you get a NIL and then you have problems > This function will create one > > function nilArray() as string() > end function > > because RB always returns something from a function you get a nil > array (not an empty one) and you cannot test it for ANYTHING > > So never return a nil array > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
