On Thu, 22 Jul 2004 10:30:20 -0700, Barney Boisvert <[EMAIL PROTECTED]> wrote: > If that's not the case, I'm of a mixed opinion. In Java, you can throw > an exception and specify the root cause, but in CF, you can't throw an > exception object, you can only throw a generic exception with a > specific name. in that case, i think it'd be better to let the > database error propogate, but the calling component shouldn't be > looking for a database exception, rather just any exception.
Or have the component catch the component and throw something more generic. Exceptions should really be considered part of the API of a component. That's why Java is fussy about the "throws" clause. If your component's API is such that it can throw database exceptions, callers should be aware of that (so catching a database exception is not breaking encapsulation - it's part of the API by definition). If your component's API is such that it can throw generic exceptions, callers should work against that contract instead - in which case catching database exceptions *would* be breaking encapsulation. What I tend to do is add that information into the hint= attribute: <cffunction .. hint="I do something.\nThrows: application/MYCFC.FAILURE" /> -- Sean A Corfield -- http://www.corfield.org/blog/ "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]
