My point was that if you catch and throw somethign else, there's no way to know anything about the original error, which may or may not be useful. So my method would "declare" that it throws exception, but actually lets the database exception propogate, specifically NOT rewrapping it.
You also can't embed any additional information in the "exception", aside from two strings (message and detail). This applies to both custom info, and rootCause info. It puts a definite crimp on exception handling. I'm getting way off base now, but say you've got a service component that creates a business object and persists it, taking in initial values for the fields of the object. I gets called by a web service facade, a HTML form processor, and a Flash RIA. Of course, before persisting, the values need to be validated. What happens if it fails? Throw a ValidationException, and pass a list of ValidationErrors to the calling code as a field of the exception object. Then the caller can do what it needs: web service will generate a fault string, the HTML form will probably redraw the form highlighting the offending fields, and the RIA could well just send the List right back to the movie for handling. Simple, elegant, and impossible with CF, because CF will only let you include string data. cheers, barneyb On Thu, 22 Jul 2004 10:51:16 -0700, Sean Corfield <[EMAIL PROTECTED]> wrote: > 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" /> > ---------------------------------------------------------- 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]
