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)>
--
--
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]
<mailto:[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]
<mailto:[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]
<mailto:[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.
