Hi Dominic
<< The single vs multiple point of exit argument has been going on for
years, made more intense by the arrival of the newer development
theories.
I find that the DO CASE...ENDCASE construct does away with such worries.
You check for all the parameters and initial validation first in the DO
CASE tests, then the OTHERWISE section contains the heart of the code
where you know that everyting is OK.
To the person who said that this construct cannot pass back meaningful
error information, it can, as I have demonstrated below. If an empty
string is returned, everything is OK, otherwise an error message is
returned
Function MyFunction (tcSomething)
Local lcErrorMsg
lcErrorMsg = ""
Do Case
Case Pcount() <> 1
lcErrorMsg = "No parameters passed"
Case IsNull(tcSomething)
lcErrorMsg = "Parameter is Null"
Case Not (Vartype(tcSomething) = "C")
lcErrorMsg = "Parameter is of incorrect data type"
Otherwise
*-- Everything is OK
EndCase
Return lcErrorMsg
I will begin using the do case instead of multiple ifs. Thanks for
that. May I suggest a slight modification to your code?
Case Pcount() = 0
lcErrorMsg = "No parameters passed"
Case Pcount() <> 1
lcErrorMsg = "Incorrect number of parameters passed"
I often recommend messages should be extremely clear. A message that
says "Your network card has melted or your hard drive has buried it's
heads in the platters" just doesn't help me find the real problem. ;)
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
