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]
