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]
