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.
