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