For most errors where I don't care if my users have useful error messages, I compile the exception struct into an email and send it to all developers in my system (currently, only me) while only showing the user "An error occurred. Contact me if you need immediate assistance." This helps me debug without always having to look through error logs.
When the error messages are relevant to my users, I use Marcus's method where I build a string containing any error messages. If Len(string) gt 0, there's an error and display it to my users, else there was no error. On Tuesday, July 1, 2014 3:16:17 PM UTC-4, Marcus F wrote: > > 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]> 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.
