>>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 totally agree. It also makes the code easier to read and understand. compound IF statements or one with several AND condition can become hard to interrupt and understand. Code should be self documenting. If a statement requires more commenting then the statement itself, then IMO it is to complex and should be re-evaluated.