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