>>>>I agree with the use of CASE statement for error control. Espacially in parameter validate at the top of procedure/methods. But, let simplify it a bit.
>>>>
>>>>

>>>>local llSuccess
>>>>llSuccess = .F.
>>>>DO CASE
>>>>   CASE NOT 1st_Logical_Test
>>>>   CASE NOT 2nd_Logical_Test
>>>>   CASE NOT 3rd_Logical_Test
>>>>   OTHERWISE
>>>>       *-- Actual code goes here.
>>>>       llSuccess = .T.
>>>>ENDCASE
>>>>RETURN llSuccess
>>>>

>>>>
>>>>I, also, general place a error message in the false CASE blocks to notify the caller as to why the routine failed.
>>>
>>>This is what YAG does regularly in COM Codebook, and I tend to disagree with JimN on this one. This is, IMO, an elegant use of the fall-through property of the DoCase construct. It has to perform all the logical tests to reach the success clause, and the first failure precludes the execution of other tests.
>>>
>>>To me, this looks like the standard checklist approach:
>>>

lCanDrive=.f.
>>>do case
>>>   case not this.HaveCar()
>>>   case not this.HaveLicense()
>>>   case not this.drunk()
>>>   case not this.tired()
>>>   case not this.car.tank.empty()
>>>   ...
>>>   otherwise
>>>   lCanDrive=.t.
>>>endcase

>>>
>>>So, if someone doesn't have a car or a license, we don't care whether he has had a drink or two, and we surely won't check the tank in a car he doesn't have.
>>>
>>>I don't see anything wrong with this approach, on the condition that the method names are meaningful.
>>
>>I like and use the approach, but unlike some other languages, you have to remember that a VFP case statement only evaluates until it finds the first match, then drops out of the case statement. All other case statements are disregarded, so the order of your cases is sometimes critical. It can be a dangerous approach, if you aren't aware of the fact that the case statement only runs until it evaluates a true condition.
>
>As I also replied to Jim, a thorough knowledge of the default behavior of VFP is what can and should be expected from professional VFP-developers. And a professional developer is allowed to expect that the next developer in line will also be a professional.


True, but if you work in several languages, and VFP isn't your primary, it's worth reminding.