- When a cfthrow errorcode="1" occurs, the method onError() at Application.cfc is fired.
- That method includes an exception.cfm that calls our showError() function, passing the error code (arguments.exception.code) as argument.
- The showError() (our custom function, in our custom componen) displays the message to the user.
We also improve the system (depending on the application needs), adding an URL to redirect after the message, and the way we want to display the message (javascript popup, in the browser window, etc).
-- Fabio Terracini
Jared Rypka-Hauer - CMG, LLC wrote:
Adam...
Why not make the redirect URL an argument to the method? Then it wouldn't be part of the CFC...
Then again, I've just realized I have confused this thread with a different thread... so... I don't have a lot more to add here. :)
But the point remains that I'd always make a URL an argument to a method or a config param from an XML file...
Anyway...
J
On 4/14/05, Adrocknaphobia <[EMAIL PROTECTED]> wrote:
cflocation? really? I actually have never thought of that one, altough I dont think I would feel confortable with that solution because and error is then handled by the cfc itself, rather than the calling application. I mean your cfcs are fairly locked into to only being used on the application they were initially designed for. (Much like #2) You give me your cfc and and error sends the user to tonyweeg.com. If i want to change it, im knee deep in find/replaces.
Here are the 3 methods I've used:
1) Defined return. Either as a structure or a component, every methods always returns the same thing (with an error flag). So your struct has a keys like 'value' and 'error'. After calling the method you would check the error key and handle appropriately.
2) Error handling methods on all components. Much like the 'where do utility functions go', I would import methods like checkError() and getError(). When an error occurs in the cfc setError() then return. The caller is then required to checkError() and handle appropriately. (This is teamed with passing a user component on every call which is part of the security framework, errors are then stored in an array based on thier sessionID)
3) cfthrow. obviously you wrap your calls in cftry/cfcatch blocks. (Which you pretty much have to do if you are strong typing your arguments in the cfc)
#1 is pretty much worthless, and following the launch of CFMX it was hyped by certain MM employees at DevCon as the end all. But as I got deeper into cfcs I found that it doesn't bubble to the top very well and there is alot of additional code.
#2 Really works well for applications that I've developed as it fits into an error handling design that surrounds it.
#3 However when I'm developing cfcs I'm planing to share with other developers or if it may be used in an application with a different architecture, cfthrow is the way to go.
Just some thoughts.
-Adam
---------------------------------------------------------- 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]
