At 11:27 AM 5/18/2004, you wrote: Thanks for the reply, John.
I actually have the code working as you described. Most CFCs extend a base CFC in the application, and the base CFC has a logError() function that can be overridden. Believe it or not, this is actually the problem. This particular application is written in a Mach-II-like framework in which an event layer controls interactions between the "service" CFCs and the UI. Midway through the project, the specs were updated to include "remote" functionality. This means exposing a core set of the "service" CFCs as SOAP web services, completely abstracted from any notion of a "framework" or user interface. So, my goal is to create a system where exception handling is built on CTRY/CFCATCH, but the collection and storage of error data is in no way tied to a CFC or framework. This will give me the flexibility to add to the raw exception data that CFMX provides as my application dictates, and then customize the handling of the errors on an application-by-application basis. This is basically what the CFMX exception handling routines do - you get a struct with error data! I stumbled on a project started by Scott Keene over at http://www.cfoop.com. Take a look: http://www.cfoop.com/project.cfm?view=EMF A little more complex than I need, but its a good start! -- Alex >My current thought is to build a base CFC that is inherited with the >Exception handling method in it. You could also set parameters for the >function to deal with extra, or limiting the exeptions handled... and how >the exception is treated. So the question is in my mind at this point... >what features do we want in this function. (Note... this being inherited... >could be done with super... or just override it with custom function in >current CFC. Glad to work with you on one if you are interested. > >John Farrar > >> Question that is, by proxy, CFC related: >> >> I am in the process of creating an application that CFTHROWS several >different types of custom exceptions in several parts of the application. >They include: >> >> 1) Form validation errors >> 2) Business logic validation errors >> 3) Database errors >> 4) Unexpected application errors......plus a few more >> >> Each error type differs slightly in the type of context-sensitive "custom" >information that is added to the CFCATCH struct when the exception in >caught. Form validation errors and business logic errors often include a >"hint" that is added in the catch block, then read and output by the UI >layer. Other errors caught in the application have other "custom" data items >added used for logging and debugging. >> >> The end result is that various parts of the application "listen" for >specific types of errors and "process" them when they're found. ** The >problem is there is no consistency between the error data structures, how >the data is analyzed, and how the application decides what to do with the >error information. ** >> >> So, the question: has anyone done a Java-style system of using something >like ErrorManager.cfc/Error.cfc, where each exception creates a new error >object, and the ErrorManager.cfc is queried to receive error information? >> ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
