On Thu, 4 Nov 2004 09:36:04 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > It should be wherever your application can recover. The method that > calls the DB is probably not going to know how to deal with the error > in any meaningful way. The "right" method will probably be the same > method that handles any other validation errors (the ones that are > checked pre-INSERT), which is likely several steps above your actual > database call.
Yes, if you're letting the DB validate your unique username constraint (which, as we've seen, you really do need to!) then that's a business rule and the business layer is probably the right place for the exception handling. But... there's also an argument for making the DAO smart enough to distinguish duplicate username - as Phil's code shows - and putting the check down in the DAO and throwing a different type of error for that case (in other words, instead of announcing a new event, the DAO would catch the database error and if it was a duplicate it would do something like this: <cfthrow type="user.dao.duplicateuser" message="#arguments.username#"/> else it would rethrow other database errors. Note that the message contains minimal information since the DAO doesn't handle display logic). Then the business layer could catch type="user", type="user.dao" or type="user.dao.duplicateuser" and do whatever it needs. The benefit of this approach is that the business layer doesn't have to catch type="database" errors (what if your DAO doesn't use a database: the business layer shouldn't care how the user is persisted!). Exception handling is a very complex topic. You could write a multi-volume set of books on it... maybe one day I will... -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Got Gmail? -- I have 1 invite "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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]
