Now here I definitely disagree. The calling code shouldn't even know that it was interacting with a database, let alone know that a database-specific error had occurred. If there is going to be any reattempt, it should happen in the object that contains the CreateUser function, and should happen transparently to the calling object.
Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Thursday, July 22, 2004 5:58 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Making Persistant CFCs thread safe Sounds like PKViolation should extend CreateException, so the calling code will actually catch any thrown PKViolation even if it's looking for CreateException. Depending on the circumstaces (such as primary keys being externally generated), the calling code might well need to know that a PKViolation was thrown, verses a generic CreateException, so it can generate a new one and try again, rather than aborting because it thinks the DB server is down (or whatever). That's another example of the kind of flexibility that CF doesn't provide, which was the root of my comments about exception handling. cheers, barneyb On Thu, 22 Jul 2004 17:47:47 -0400, Roland Collins <[EMAIL PROTECTED]> wrote: > 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 ---------------------------------------------------------- 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]
