Hi Bill,
Normally we define errors as general, like "field xxx is required", but using Flash Forms, this kind of error is drastically decreased, so, the number os error codes (and errors messages) are a bit low, like a cftry to see if the uploaded file is the correct mime-type and critical problems.
In a CF 6.1 application, with html forms, the structure could became large, but, as you said, in this case errors are common occurances, so, store it in application scope, IMHO, is better than every time (em remeber: this is frequent) access the XML and look for the specific message. It's memory consumption vs processor usage. And it's not 100Mb of errors messages at all. Anyway, you could use this way to general error messages, critical, or both.
Also, there are a special catch in this way of error handling. We also develop Flex application, and cfthrow is a good way to return error messages (or error codes) to Flex Applications, since what you define in cfthrow is sent to Flex.
--
Fabio Terracini
Bill Rawlinson wrote:
Fabio,
are errors common occurances? I ask because, if they are, then it seems kind of excessive to store all error messages in the application scope.
Of course, I also don't know what you define as an error. If errors are just critical problems
then they are probably very rare and storing the info in the app scope is overkill.
If errors are more general, like "x user name is in use, try another" or other trivial things that could
occur very frequently then your method makes total sense.
Anyway, Just curious, hope you don't mind my asking/nose-poking
thanks Bill
On 4/14/05, *Fabio Terracini* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
In CF7 applications, we use cfthrow with errorcode="", and in Application.cfc, we handle the error. We use a configuration XML file (by language) that associate numeric error codes with messages, so, when onError() is called, we display the correct message to the user, and in his language.
Also, we parse the XML in the application start and store it in a application variable, so the error messages are in memory and we don't need to parse the XML file every time an error occurs.
--
Fabio Terracini
Tony Weeg wrote:
>Hola. > >As a practice, do you all tend to shy away from breaking out of a CFC >on error, with a cflocation? > >Just wondering. I have in the past, and I'm about to work on a new >one, and was just wondering, as a I looked at my old code. > >Thanks. > > >
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] <mailto:[email protected]> with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org <http://www.cfczone.org>) and supported by CFXHosting (www.cfxhosting.com <http://www.cfxhosting.com>).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected] <http://www.mail-archive.com/[email protected]>
-- [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://blog.rawlinson.us
If you want gMail - just ask. ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
