I think we actually agree 100% on the error handling responsibility part. I guess what I should have said is that it's not good to let _all_ exceptions propagate up the call stack. Certain types need to be caught and handled and/or re-cast as a different type of exception.
For instance, an object using a DAO to create a user shouldn't really know that there was a primary key violation during an insert. It should probably get a more application-specific "CreateUserException". That way, if you ever change the underlying storage mechanism, the calling code doesn't need any changes because it wasn't looking to trap a "PKViolation", it was looking to trap a "CreateUserException". Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Thursday, July 22, 2004 5:33 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Making Persistant CFCs thread safe If we're talking about a couldn't connect to database, or invalid sql or something like that, then sure, the fact that the exception was through is all the info you need, but that kind of situation is only half of what exceptions are designed to do. Take my example of a ValidationException, which would be an application or checked exception, and consequently expected to be recoverable. Not all exceptions should terminate processing. If you want to continue processing after an exception, you'll very likely need additional information about the specifics of the exception (the specific validation errors, in this case), along with the fact that an exception occurred. In that case, would be breaking encapsulation for the object that threw the exception to do the cleanup, encapsulation demands that the cleanup be done by the calling code. cheers, barneyb On Thu, 22 Jul 2004 16:29:58 -0400, Roland Collins <[EMAIL PROTECTED]> wrote: > But objects outside of the object in which the exception occurred should not > be responsible for cleaning up the mess left behind by the object. That > breaks encapsulation. Calling objects _may_ need to receive an exception, > but that exception should really just be a notification to the callers that > an operation has failed and that they should clean up their own resources. > Callers shouldn't need to know about the state of the resources in the > callee. > > Roland ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
