Ok, so it took me two days to read through this thread. Sue me. ;)
If your query fails, the component doing the query should throw an exception, which is handled by the calling code. It shouldn't pass back a valid value unless the operation was successful (or at least successful enough). That's the point of exceptions, after all.
Big plus one to this. I can't see why you would want to supress the error.
This may be an excessively fine point, but I think suppressing the error is exactly what he meant.
I read Barney to mean that if the function fails, it should throw an exception. The calling code shouldn't need to know that the function is calling a database in order to examine the exception as a database error. If the query fails, the function should catch it, understand it, and if the failure causes the function to fail then the function should throw an exception back to the calling code. But, IMO, to throw the raw query failure back is breaking encapsulation, so you must suppress that in the function and replace it with something function-specific
That said, I hardly adhere to such a rigorous rule 100% of the time, but since we're talking about ideals here I figured I'd chime in.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067----------------------------------------------------------
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]
