Earlier in this post I had said I could *NOT* step into the DoDefault() code when uit was inline with Return... Well, now today I can step into it. So, clearly, something was whacked up last night. So, sure I'll go ahead and that it does work.

Either way, I'm now committed to the consitent pattern in my code of capturing the return value to a local var. Even for short atomic methods (like they should all be anyway, right?)


>Maybe, last night, at one point you were inadvertently accessing a different version of your base class, that at one point was not returning _TALLY, but something else instead (?) One mistake I make sometimes is to improperly comment or uncomment code, so I get unexpected results.
>
>AFAIK _TALLY is never anything other than numeric. If you try _TALLY = .T. in the Command window, you get a Data type mismatch error.
>
>As Paul points out, your code ( RETURN DODEFAULT( ) ) should work fine. As for actually using it - sometimes I do, sometimes I don't.
>
>The biggest drawback, as Craig points out, is it's a little more difficult to debug. Rather than just hovering over lnRetVal to see what the return value will be, you have to step into the parent class method and follow it to completion.
>
>There are some benefits to avoiding the LOCAL lnRetVal ... lnRetVal = ... construct:
>
>- if the method gets called a lot, performance is improved
>- if you can avoid code, you can avoid potential bugs. For example, if someone later removes the LOCAL statement, and there is another lnRetVal in scope, you can get hard-to-track bugs. Also, if the current ALIAS() contains an lnRetVal column, that'll get used if you don't mdot it ( RETURN m.lnRetVal ).
>- if your methods are small and atomic (i.e. do one simple thing efficiently), using the variable declaration means reading more code, which as a style thing some people might find tiresome
>
>In practice, if I'm writing a method that's doing something non-trivial I usually already have an l(x)RetVal variable set up which I return at the end. I got into that habit when I started writing fault-tolerant code, where I had to know if a given function call worked as expected.
>
>Plus, I had a tyrant of an instructor in an introductory C programming course I took 25 years ago, who said "Every function must return a value" ;)
>
>>Well, your code indeed works fine.
>>
>>And, I've gone back to my own code, and now I cannot get it to repeat the results I was getting last night.
>>
>>I *KNOW* for sure that is was not working correctly, but today I cannot replicate it.
>>
>>However, I still am resolved that I like my modified coding sequece anyway, so I'm still going to abandon the Return DoDefault() structure going forard.
>>
>>
>>
>>>>Some of you probably already knew this, but it caught me off guard...
>>>>
>>>
>>>Are you sure that's what's happening? Are you sure your base class always returns a number (and doesn't have some cases where it just does a RETURN out of the code)?
>>>
>>>I tried it and it works fine:
>>>
>>>

>>>o = CREATEOBJECT("TestB")
>>>?o.DoSomething("")
>>>
>>>DEFINE CLASS TestA AS Custom
>>>   FUNCTION DoSomething(tcString)
>>>      RETURN 1
>>>   ENDFUNC
>>>ENDDEFINE
>>>
>>>DEFINE CLASS TestB AS TestA
>>>   FUNCTION DoSomething(tcString)
>>>      RETURN DODEFAULT(tcString)
>>>   ENDFUNC
>>>ENDDEFINE
>>>