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]> 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)>
>>
> --
> --
> online documentation: http://openbd.org/manual/
> http://groups.google.com/group/openbd?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Open BlueDragon" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> --
> online documentation: http://openbd.org/manual/
> http://groups.google.com/group/openbd?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Open BlueDragon" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
---
You received this message because you are subscribed to the Google Groups "Open
BlueDragon" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
