On 10/23/05, Nathan Dintenfass <[EMAIL PROTECTED]> wrote:
> I am curious to know, though, if this is considered a "bug"
The 7.0.1 release notes say this (as an issue that is fixed in 7.0.1):
55781 If you create a method in a CFC or a UDF in a page, and use
cfscript exception handling, the catch structure cannot be created if
you already declared the variable name as a private variable.
In other words, if you have the local variable, the code is actually
broken even tho' it may seem to work. I had a look in the bugbase and
it's quite a subtle issue.
The bugbase indicates that you (Adam) are the originator of the bug.
Paul Hastings also ran into the bug.
"If you create a method in a CFC or a UDF in a page, and use CFSCRIPT
exception handling, the catch structure cannot be created if you've
already declared the variable name as a private variable. Also, when
the variable is populated, it always CFDUMPs as a structure, but it is
a Java Object (isObject() returns "YES" but isStruct() returns "NO")."
The bugbase comments note that the second part is by design but goes
on to say the following about the first part:
"the error message depends on how you've declared the private
variable. Usually it's either a message that the key does not exist
in the structure, or it's an error stating that you've attempted to
dereference a scalar. This behaviour is the same in ColdFusion MX 6.1
and Blackstone Alpha 1."
The issue is that the local variable stops the catch variable being
created (or hides it) and so keys in the catch struct don't exist.
Here's the reproducible case (with the explanatory text edited
slightly):
...quote:
In Blackstone or CFMX 6.1: Create a function, declare a private
variable at the begining of the function, create a try/catch in
CFSCRIPT and put code that throws an error in the try. In the catch
arguments use the name of your private variable as the name of the
catch variable to create and populate, in the catch block try to
reference any of the keys (such as "message") that should be in that
error structure. If you remove the private variable declaration it
stops throwing an error. To reproduce, copy and paste all of the code
from here down into a file and browse the file:
<!---::
Note that if you leave the private variable declaration for "e" the
catch structure cannot be created!
Comment out the first "var" statement in the function and it all of a
sudden works!
::--->
<!---:: a function that divides 100 by it's argument ::--->
<cffunction name="divideonehundred" access="public" returntype="string">
<cfargument name="divisor" required="true" type="numeric">
<cfscript>
var e = "";
var retVal = "success";
// generate error
try{
retVal = retVal & " (" & 100/arguments.divisor & ")";
}
catch (Any e){
retVal = e.message;
}
</cfscript>
<cfreturn retVal>
</cffunction>
<cfoutput>
<!---:: this call should work ::--->
The result of dividing 100 by two is: #divideonehundred(2)#<br />
<!---:: this call will cause an error to be thrown ::--->
The result of dividing 100 by 0 is: #divideonehundred(0)#<br />
</cfoutput>
...endquote
The local declaration of 'e' and initialization as a string broke the
e.message usage in the catch() clause. The bug notes say that the
decision was made to follow Java (not allowing the catch() variable to
conflict with any other local variables) in order to resolve the
problem. (so I was wrong about exactly what Java allows but right that
CFML is following Java now in 7.0.1)
Hope that clarification helps?
--
Sean A Corfield -- http://corfield.org/
Got frameworks?
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]