Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Checking Parameters
Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01108949
Message ID:
01108971
Views:
12
So assuming you are expecting a string parameter, and the user passes a number,
what do you do.

Optional or not, all params need to have their type checked.




>Here's how I do it:
>
>Any parameters that are required go first. Optional parameters follow. That way, I only have to do
>
>IF PCOUNT() <= "number of required params"
>
>Then for the optional parameters, I check the data type. If logical and false, it wasn't passed, so I give it a default value. Something like:
>
>
>tcParam5 = IIF(VARTYPE(tcParam5) = "L" AND !tcParam5, "default value", tcParam5)
>
>>This is a bit long, but I need to explain my question clearly.
>>
>>I want a consistant way to check parameters passed into COM objects.
>>
>>Right now, I use something like the following:
>>
>>
>>PROCEDURE MyProc(aSomeArray AS Variant) AS Boolean HELPString "This method does..."
>>WITH This
>>
>>  IF PCOUNT() = 1
>>
>>    IF TYPE("aSomeArray[1]") # T_UNDEFINED
>>
>>      ** Code for this method goes here
>>									
>>    ELSE
>>      ERROR 232, "aSomeArray" && 'aSomeArray' is not an array
>>    ENDIF
>>			
>>  ELSE
>>    ERROR 1229 && Too few arguments
>>  ENDIF
>>
>>ENDWITH
>>
>>
>>Problem is, this is a lot of code for only 1 parameter. With methods that take 4 or 5 parameters, this
>>could get really ugly.
>>
>>I am considering switching to something like:
>>
>>
>>PROCEDURE MyProc(aSomeArray AS Variant) AS Boolean HELPString "This method does..."
>>WITH This
>>
>> IF .CheckParams("MyProc", @aSomeArray)
>>
>>   ** Code for this method goes here
>>
>> ENDIF
>>
>>ENDWITH
>>
>>
>>HIDDEN PROCEDURE CheckParams(sProcName, p1, p2, p3, p4, p5) AS Boolean
>>
>>  LOCAL bRetVal AS Boolean
>>  bRetVal = TRUE
>>
>>  WITH This
>>
>>   DO CASE
>>
>>     CASE sProcName = "MyProc"
>>      DO CASE
>>        CASE TYPE("p1") # T_LOGICAL
>>          ERROR 1229 && Too few arguments
>>          bRetVal = TRUE
>>
>>        CASE TYPE("p1[1]") # T_UNDEFINED
>>          ERROR 232, "aSomeArray" && 'aSomeArray' is not an array
>>          bRetVal = TRUE
>>
>>      ENDCASE
>>
>>   ENDCASE
>>
>>  ENDWITH
>>
>>  RETURN bRetVal
>>
>>ENDPROC
>>
>>
>>I welcome any thoughts/input on this.
>>
>>Thanks
Everything makes sense in someone's mind
public class SystemCrasher :ICrashable
In addition, an integer field is not for irrational people
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform