Hi Kevin

Message: 4
Date: Mon, 26 Jun 2006 08:11:23 -0400
From: Kevin Cully <[EMAIL PROTECTED]>
Subject: Strong parameter checking
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
   LOCAL lcRetVal
   lcRetVal = []
   IF PCOUNT() = 1
      IF NOT ISNULL(tcSomething)
         IF VARTYPE(tcSomething) = "C"
            IF NOT EMPTY(tcSomething)
               lcRetVal = [My Function ] + tcSomething
            ENDIF
         ENDIF
      ENDIF
   ENDIF
   IF EMPTY(lcRetVal)
      =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
        "  Try again."
   ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

Personally I find it easiest to check parameters first and get out if
necessary and then follow with the heart of the function. This clearly
separates the two steps and the meat of the function is cleaner and
easier to follow.

FUNCTION MyFunction(tcSomething AS String) AS String
  LOCAL lcRetVal
  lcRetVal = []
  IF PCOUNT() = 0 OR VARTYPE(tcSomething) # "C"
    RETURN lcRetVal
  ENDIF

*Now the real meat of the function is not tabbed way over for nothing.

RETURN lcRetVal
ENDFUNC

Mike


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

Reply via email to