I'd love to see what you guys are doing, I'm playing around with 
error-checking myself.

Currently I'm initializing a variable such as var errorInfo = "", any error 
is processed and a message explaining it put into the variable, I then just 
check the length of the variable, if it's longer than 0 chars, there's an 
error.

On Tuesday, July 1, 2014 2:13:11 PM UTC-5, MiniFireDragon 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] <javascript:>> 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] <javascript:>> 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] <javascript:>.
>>> 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] <javascript:>.
>>> 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] <javascript:>.
>> 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] <javascript:>.
>> 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] <javascript:>.
> 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.

Reply via email to