In my case if the query was removed completely the application would still work correctly. It would simply return no records.
What my method does is it leaves out some verbosness in the exception handler and allows the application to fail gracefully.
Of course there is always situations that can not fail gracefully and in those cases you would leave that up to your error handler to return a nice message to the screen.
It also allows you to easily glance at function and know what the vared variable types are.
It also allows functions to more easily be written to check the validity of other functions such as unit testing software, auto generation of function containers, etc.
Of course this discussion is always going to be a preferance between differant developers and is not required to have functioning code (outside the fact that they must be vared, whether you explicity assign their types or not).
In that case if one agrees with me and one agrees with you and they are not sure whether they will always want to do it that way, they could write a varValue() function that would return a var into whatever type they wish it to be. If they decide they no longer like my method they could easily just change the varType for the object in the initialization of the varValue function.
Barney Boisvert wrote:
----------------------------------------------------------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.
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]
