>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.