>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield
>Sent: Thursday, June 03, 2004 11:02 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [CFCDev] Catching Argument Type Errors
>
>On Jun 3, 2004, at 11:48 AM, Stephen Milligan wrote:
>> Sounds like we could use a 'throwOnError' attribute for either the
>> cffunction or cfargument tag, maybe both.
>
>Why?
So that a webservice can create WSDL that tells you what the type should be
for any argument, but you still retain control over what happens if the
passed argument isn't of the correct data type.
>What would you expect to happen if you said throwOnError="false"?
The function would act as if the type attribute had a value of "any"
>How would you handle the error and why would that be different
>from doing the following:
>
> <cfargument name="arg" type="any" required="true" />
> <cfif isNumeric(arguments.arg)>
> ... normal processing ...
> <cfelse>
> ... error processing ...
> </cfif>
>
It would be different because you would be doing the error processing rather
than CFMX.
That gives you control over, among other things, the error message. That
would allow you to add some meaningful text to the error rather than the
standard CFMX message.
>> Something that works the same as the cfhttp attribute. Then
>you could
>> have the wsdl specify the required parameter type and do the
>checking
>> yourself in a webservice situation.
>
>But if you are calling it as a web service you *can* catch and
>handle the error:
>
> <cftry>
> <cfset ws.callMethod("not a number") />
> ... continue with processing ...
> <cfcatch type="any">
> ... do something with the error ...
> </cfcatch>
> </cftry>
Yes, but if I'm consuming a webservice that someone else wrote and am
getting the standard CFMX error, I might well not understand what it is
telling me. Given that many consumers may not be familiar with CFMX.
As the publisher of the webservice I might also want to log some specific
info when there are errors with data types.
It's just giving a bit more granular control to the publisher of the
webservice, or of a method for that matter.
The same thing applies if you create a CFC that other people may want to use
within CFMX. If you can provide them with better info about why their
function call might be failing so much the better.
Spike
----------------------------------------------------------
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]
