Cheers for the info. The way i have it going at the moment, is that at the function level, i check for db execeptions, then i check that the result passed back to the caller, is correct format/type, and (if not blah) throw an error, but if its not blah, but is blah, carry on executing the template.
one final question though. If an error is thrown from within my cfc, the catch creates a request.error object through a request facade, whcih is then picked up the onrequestend.cfm. This is though breaking excapsulation is it not? I have ahd a quick think about it, and i dont think this can be helped. Is this just the way it has to be? cheers Jamo > You need to be careful taking this approach. > > The further an error is propogated from where it is thrown, the more > likely it is that you'll have some code that modified something with the > expectation that a later piece of code will execute. > > This blog post from Raymond Chen does a good job of explaining the type > of problems it can cause. > > http://weblogs.asp.net/oldnewthing/archive/2004/04/22.aspx > > Spike > > Barry Beattie wrote: > > Jamie, > > > > my view is to try to move the error catching further up the call stack, > > to best deal with it in relation (or context) to how it was called - the > > error belongs to that, not the atomic piece of logic that was called. > > > > if you've got a private (helper) function that checks "variables.table", > > it's what the eq "" means to the call in the public method that should > > dictate whether it's an error or not. > > > > what happens if ** variables.table eq "" ** is indeed valid in some > > cases and is used as a trigger for conditional logic? it's what the eq > > "" means in the call's context that should dictate whether it's an error > > or not. > > > > What we have here, though, are exceptions - application/business logic > > errors, not db or file errors, etc. but the same idea applies: > > > > try { > > add a new user (call to many methods) > > } > > catch any error{ > > "sorry, can't be done. come back later" > > } > > > > you can still interrigate the call stack for logging, etc, for specific > > information. > > > > > > just my 2c - anyone else want to chime in? > > barry.b > > > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Gavin > > Stewart > > Sent: Tuesday, 19 October 2004 12:27 PM > > To: CFAussie Mailing List > > Subject: [cfaussie] Re: try in cfc? > > > > The best way to do this is to customise your errors in your cfcs - > > because > > the error will not be caught if you wrap it around the calling code > > e.g > > > > <cfif variables.table eq "" > > > <cfthrow type="TABLE_NOT_DEFINED" > > > </cfif> > > > > hope this helps > > Gav > > > > "Jamie Lawrence Jenner" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > >>hi folks, > >> > >>justa quicky > >> > >>what is the best method to error catch. Wrap specific functions within > >>cfcs in cftry/catch blocks, or the calls to these fucntions in > > > > cftry/catch > > > >> blocks? or both? > >> > >>my inkling is to wrap the calls in try/catch blocks > >> > >>cheers > >> > >>jamo > >> > >> > > > > > > > > > > --- > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > > [EMAIL PROTECTED] > > Aussie Macromedia Developers: http://lists.daemon.com.au/ > > > > > > > > > -- > > -------------------------------------------- > Stephen Milligan > Code poet for hire > http://www.spike.org.uk > > Do you cfeclipse? http://cfeclipse.tigris.org --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
