Re: [OpenBD] Re: How would you construct this function differently?

Ernest McCloskey Tue, 01 Jul 2014 12:23:22 -0700

My newer coding for error checking I return structures. Usually withst.error=x st.msg="This is what you did wrong". And with CFCATCH forsomethings you can get the error message given by OpenBD, in that case Iwould add st.detail="cfcatch info."

And depending on security, if it is unsecure data I let the USER PCdetermine how to handle it, if there is security require the serverhandles it.


On 7/1/2014 3:14 PM, Jason King wrote:

Cool, thanks. I haven't had any problems with that yet.

Which error logic do you prefer? Individual vars for each error type,or one error var and a memo?

On Tue, Jul 1, 2014 at 2:10 PM, Ernest McCloskey<[email protected]<mailto:[email protected]>> wrote:


    or 1 = OK and 2 = Errors.


    On 7/1/2014 3:06 PM, Jason King wrote:

    If there's an error, I would flip it to 1. So any logic looking
    for errors would ask  if error = 1 then YOU HAVE ERRS

    Is that what you're suggesting? If error, set the var to 1?


    On Tue, Jul 1, 2014 at 2:01 PM, Ernest McCloskey
    <[email protected]
    <mailto:[email protected]>> wrote:

        Just to interject on returning 1/0 as an error message, it
        has been my experience (and has occurred in current software
        versions) there are times OpenBD will not return a 0 (via
        CFAJAX),  either as "0" or 0.  And yes, the bug was reported,
        but it was a random occurrence that happened to frequently to
        be reliable.  However, after switching to sending 1 instead
        of 0, problems stopped occurring.


        On 7/1/2014 2:24 PM, Jason King wrote:


        Thanks guys!

        Onto another question.

        How do you handle errors?

        I have several ways in mind to approach this. Here's the 2
        I'm thinking about.

        1) create a var for each possible error, and flag that
        specific var if a specific error is thrown

        ie

            <cfset var functionResults=StructNew()>
            <cfset functionResults.error = 0>
            <cfset functionResults.errorInvalidEmail = 0>
            <cfset functionResults.errorInvalidUserID = 0>
            <cfset functionResults.errorInvalidState = 0>
            <cfset functionResults.errorInvalidCountry = 0>

            <cfif not isNumeric(arguments.userID)>
              <cfset functionResults.errorInvalidUserID = 1>
            </cfif>

        This way, the return set is simple.. just 0/1's for each
        possible error.
        Advantage is that I can return a 0/1 for an error and don't
        have to include any description. The error var itself
        describes the error.
        Disadvantage is that the app has to be coded to interpret
        each error. Upside is this leaves the app designer to
        provide the language that describes the error.


        2) create a single error var and a single errorMemo var. As
        errors are thrown, the error (invalid user ID) is added to
        the errorMemo var. It returns a single error flag, as well
        as a reason for the error


            <cfset var functionResults=StructNew()>
            <cfset functionResults.error = 0>
            <cfset functionResults.errorMemo = 0>

            <cfif not isNumeric(arguments.userID)>
              <cfset functionResults.error = 1>
              <cfset functionResults.errorMemo = "UserID Invalid" >
            </cfif>

        Advantage here is that there's a single error var, and the
        actual errors are described. So if there's an error, the app
        can be coded to simply display the errorMemo variable that
        was raised.

        Thoughts?


        On Mon, Jun 30, 2014 at 4:54 PM, 'Alan Holden' via Open
        BlueDragon <[email protected]
        <mailto:[email protected]>> wrote:

            +1 to Ricky (Rawk)

            Most of my methods always declare everything, and also
            return as much as technically possible with every call.
            The one var to watch is the "success" code.

            If that one's false, then most everything else will be
            valueless (except perhaps the message structure, which
            explains why success was false), but at least they will
            all still BE THERE!

            No sense clotting up your calling processes with a bunch
            of "but first, does is it exist?" code.

            Al


            On 6/30/2014 1:30 PM, Rawk wrote:

            It's really your preference as you generally won't
            stand to gain any increased performance by doing it one
            way or the other.  The only other thing to consider is
            readability and patterns of your code.

            My preference is to declare all local variables
            immediately and initialize them as best as I can.  If
            initialization is based on a conditional, I will
            declare them with "empty" values first. That way I can
            always see my arguments and local variables at the top
            of my functions and don't have to dig around IF logic
            to find them all.


            On Monday, June 30, 2014 1:06:54 PM UTC-4, Jason Allen
            wrote:

                Hey Guys,

                I got another question.

                In some of my more complex cffunction declarations,
                there's some functions that I run only if certain
                requirements or met. So there might be 6 different
                function calls, but maybe only 1 or 2 will be used
                depending on the arguments passed.

                For instance, as part of a larger 'login'
                cffunction declaration, I have the following
                function call. Thing is, it's part of the code
                that's most likely going to be rarely used.

                <cfset var hashPassResults =
                application.users.hashPass(password=arguments.password,
                userSalt=getPassInfo.userSalt)>

                My question is; should I declare this at the
                beginning of the function, then use the 2nd line
                when it's actually used. Or is it ok to declare the
                call the function and declare it as var in one
                statement? This would avoid declaring a variable
                that's rarely used until it's actually needed.

                     Start of function:

                <cfset var hashPassResults = structNew()>

                      then when actually used...

                     <cfset hashPassResults =
                application.users.hashPass(password=arguments.password,
                userSalt=getPassInfo.userSalt)>

                or do it all when used and don't declare it if not
                needed

                 <cfset var hashPassResults =
                application.users.hashPass(password=arguments.password,
                userSalt=getPassInfo.userSalt)>