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]
