If I had my druthers, I'd put the try/catch in the calling program, since it's the one that knows how to handle the error. And if there is a validation error in the insert method, I'd throw an error.
> > I'm a bit confused. So is Eric saying the method that handles the actual > database insert not return any error information? I want the calling > application to know whether or not the insert failed or succeeded. And if > it > failed, I would think that you would want to know why (without wrapping > the > method call in try block). > > I was thinking of using the -error key of my return structure to return > other types of errors as well (validation maybe) and not just the cfcatch > structure. The value of the key might contain something like the > following: > > Error: > type = validation > message = array of validation errors > > Error: > type = coldfusion > message = CF error message > > Error: > type = data > message = duplicate entry > > <cffunction name="InsertPage" access="package" output="false" > returntype="struct"> > > <cfargument name="objPage" type="Page" required="yes"> > > <!--- check for validation errors ---> > <cfset var aValidationErrs = validate(arguments.objPage)> > > <!--- if there were validation errors; return ---> > <!--- TODO: Change arraylen to ValidationError() function for easier > reading ---> > <cfif arraylen(aValidationErrs)> > > <cfset stReturn = objCMS.buildDataReturnStruct(false, > "validation", aValidationErrs)> > <cfreturn stReturn> > > <cfelse> > > <cftry> > <cftransaction> > <cfquery name="q_pageInsert" > datasource="#stSettings.dsn#"> > INSERT foo > </cfquery> > <!--- TODO: Get newly inserted pageid and > set in objPage ---> > </cftransaction> > > > <cfcatch type="database"> > > <cfset stReturn = > objCMS.buildDataReturnStruct(false, "coldfusion", cfcatch)> > <cfreturn stReturn> > > </cfcatch> > </cftry> > > <cfset stReturn = objCMS.buildDataReturnStruct(true, "", "", > arguments.objPage)> > <cfreturn stReturn> > > </cfif> <!--- validation errors ---> > > > Thanks for the help, > Phillip > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of [EMAIL PROTECTED] > Sent: Tuesday, September 30, 2003 8:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Returns from a data layer method > > I agree with Eric, but my coworker didn't, so we went with something close > to #3 (but it doesn't return timestamp or object). We're doing this: > > <cffunction name="add" returnType="any" hint="returns a struct or cfcatch > (which is like a struct but causes returntype='struct' to error)"> > <cfset var stErr = structNew()> > <cfset stErr.nativeErrorCode = 0> > > <cftry> > <cfquery name="qi" datasource="#keep.Meta.dsnName#"> > INSERT INTO blah blah blah > </cfquery> > <cfcatch type="database"> > <cfset stErr = cfcatch> > </cfcatch> > </cftry> > <cfreturn stErr> > </cffunction> > > The calling program has to check the return structure's nativeErrorCode to > see if there was an error. > > >> I once heard a programmer's joke that said, "Don't check for an error > you don't know how to handle." >> >> The more I thought about it, though, the more it made sense. How do I > know what the calling application wants to do? If I throw the exception > back to the caller, different applications may have totally different > needs > for how to handle it, so I should let them do their thing. I've actually > had applications that did not perform properly because the errors were > trapped too early and the module took the wrong "corrective" > action. >> >> Thanks, >> Eric >> >> >> >> >> "Dave Carabetta" <[EMAIL PROTECTED]> >> Sent by: [EMAIL PROTECTED] >> 09/30/2003 10:28 AM >> Please respond to cfcdev >> >> >> To: [EMAIL PROTECTED] >> cc: >> Subject: Re: [CFCDev] Returns from a data layer method >> >> >>>I'm just wondering what are some best practices for returning values >> after >>>an actual database operation. I have a data layer object that handles >> doing >>>things such as inserts and updates to actual database records. For > instance, >>>I have a InsertPage(Page) method that takes an instance of a 'Page' >> object >>>and does a database insert. What should I be returning from the >>>InsertPage() >>>method? Should it be: >>> >>>1. a boolean indicating success of failure 2. id of new record 3. a >>>structure containing the following keys: >>> - status (success or failure) >>> - error (structure with type and message keys) >>> - obj (the updated object) >>> - timestamp >>>4. something else? >>> >> >> For me, it's #4 -- something else. >> >> I wrap my method calls themselves in a cftry/cfcatch statement and >> trap for any errors (read: not the query itself). If the database >> throws an > exception, then it's up to me to account for the different ways it might > fail (i.e., duplicate primary key) in my calling code and trap the > returned >> error code accordingly. That's obviously for inserts, updates, and > deletes. >> If it's a select statement, then I use a returntype of query and go >> from > there. >> >> If you use cftry/cfcatch, then everything you'd want out of #3 is >> available to you is the cfcatch structure that's generated. >> >> That's just the way I do it. Others may have their own preferences. >> >> Regards, >> Dave. >> >> _________________________________________________________________ Help > protect your PC. Get a FREE computer virus scan online from McAfee. > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 >> >> ---------------------------------------------------------- >> 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). >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[EMAIL PROTECTED] >> >> >> >> > > > > ---------------------------------------------------------- > 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). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > > ---------------------------------------------------------- > 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). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- 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). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
