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).
