I agree with throwing rather than custom exception structures being returned and handled. I don't think there is anymore overhead using cftry/cfcatch in a CFC than there is in normal CF code, and even still it is small. I bet it's relatively the same overhead as the custom handling code you will be writing to handle your custom exception message returns!
Of course, deciding what qualifies as an exception and what doesn't is another matter and somewhat subjective, based on your CFC/application's needs and requirements. If your CFC catches an exception that still allows the CFC to fulfill it's contract (return proper values or do work as expected), then it may be perfectly okay to handle it there, return a custom flag to the caller or just move on. All of this depends on your situation. My rule of thumb is: if my CFC can't fulfill it's contract, then an exception should be thrown (and I use the CF exception throwing features). Scott -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kola Oyedeji Sent: Wednesday, July 16, 2003 11:27 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Stand-Alone CFCs? This is interesting. This has been hotly debated before. Not just in the CF world but the Java world as well. My personal opinion is that due to the overhead (albeit quite small) involved in wrapping code in a try/catch block I would prefer to use the structure with error message route. Of course this then means that the value has to always be checked which leads to slightly more work. I suppose it depends on how much of a performance hit is involved in wrapping CFCs or a particular CFC in a try/catch block Kola >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Raymond Camden >> Sent: 16 July 2003 16:14 >> To: [EMAIL PROTECTED] >> Subject: RE: [CFCDev] Stand-Alone CFCs? >> >> I know many people return a struct w/ error info in it, but to me it >> makes more sense to throw. CF has a native exception type system, so why >> not use it? >> >> ======================================================================== >> === >> Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc >> (www.mindseye.com) >> Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) >> >> Email : [EMAIL PROTECTED] >> Blog : www.camdenfamily.com/morpheus/blog >> Yahoo IM : morpheus >> >> "My ally is the Force, and a powerful ally it is." - Yoda >> >> > -----Original Message----- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED] On Behalf Of Bryan F. Hogan >> > Sent: Wednesday, July 16, 2003 9:08 AM >> > To: [EMAIL PROTECTED] >> > Subject: RE: [CFCDev] Stand-Alone CFCs? >> > >> > >> > Ok with that, should when an error is thrown by the CFC, >> > throw out to CF via cfthrow or should it contain it's own >> > exception handling and return error values to the developer >> > who is using the CFC? >> > >> > For an example when a user does not follow directions on how >> > to use the CFC properly by passing it the correct arguments. >> > Such as if you have a CFC that does DB access using cfquery >> > and it needs the DSN var that is normally in the Request >> > scope of the application the CFC resides in. >> > >> >> ---------------------------------------------------------- >> You are subscribed to cfcdev. To unsubscribe, send an email >> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' >> in the message of the email. >> >> CFCDev is run by CFCZone (www.cfczone.org) and supported >> by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
