I'm pretty sure the mach-ii.info sample app returns a error structure from all of its objects (though, really, it doesn't it is just setup to do so and instead it throws exceptions when an error occurs) and I think that (returning the struct) is probably the smartest way to do it.
A struct is a fine way to store the error information and your app can then process the errors as you want (or ignore them - not something I necessarilly advocate) - plus a struct is a pretty darn generic CF object that anyone accessing the app will be able to "consume" be it via a local application, a web service, what have you. Now, you might have an error handler object that processes the error struct and generates messages or whatever to display or email off to the developer etc at some point in your app - but I wouldn't have it as a known object throughout your cf app as is. On the flip side I could see having a utility object say, ErrorLog, that you invoke throughout your app. then whenever an error occured you could log what object the error occured in, the method generating the error, and any other pertinant information. This ErrorLog object could then either write a log message or email the developer - or whatever you wanted it to do. Objects aren't necessarilly supposed to live in total isolation from all other things. Sure, you want as little coupling as possible but but you still want an application that does what you need it to. Then again, I may be rambling. It is 2am and I'm pretty tired. Gnight Bill ---------------------------------------------------------- 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]
