> 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).
You're absolutely correct that it's personal preference, and you can write a working application either way. However, almost anyone will tell you that a clear breakdown of roles within the application's code (abstraction and encapsulation) makes it easier to do maintenance and updates down the road. Combining the logic to both perform the query and determine whether a failure is recoverable (and therefor an alternate dummy recordset should be used by the caller) is definitely not an example of those traits. Code block one should do a query, and either throw an exception or return the result. Code block two should either let program flow pass on (no exception) or catch the exception and respond accordingly. The response might be to let the error propegate to the user, to redirect to an error page, or to generate a dummy recordset that can be used in place of the "real" recordset and let program flow pass on. The first code block shouldn't have enough information about the app's overall function to be able to make that decision, or you run the risk of ending up with spaghetti logic. I'm not saying that combining them is necessarily wrong, but doing so it s a good way to paint yourself in a corner. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bryan F. Hogan > Sent: Tuesday, July 20, 2004 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Making Persistant CFCs thread safe > > If you returned an exception and did not want the exception > to display > to the user you would write an exception handler possibly > returning an > empty query so that the view would not display an exception, > instead it > would simply not display containing information in that query. > > 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. ---------------------------------------------------------- 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]
