Raymond Camden's ColdFusion Blog: Always var scope! Always!! Except...

Always var scope! Always!! Except...

So, I ran into an interesting issue today. We had some UDFs written in cfscript that used try/catch. The object defined in the cfcatch block was var scoped since... well... we always var scope, right? Consider this code block:

<cfscript>
function foo() {
   var myerror = "";
   x = "apple";
   try {
   if(x+9) x = 1;
   } catch(ANY myerror) {
      writeOutput(myerror.message & "<p>");
   }
}
</cfscript>

<cfoutput>
#foo()#
</cfoutput>

Everything looks hunkey-dorey, right? However, running this will give you: You have attempted to dereference a scalar variable of type class java.lang.String as a structure with members.

Turns out - the var scope of myerror seems to prevent it from being used in the cfcatch block. If you remove the var scope, not only does the code work right, it won't overwrite a variable called myerrors that may exist in the Varibles scope.

This entry was posted on Wednesday, March 2, 2005 at 4:50 PM. It was filed in the following categories: ColdFusion. It has been viewed 4,955 times and has 11 comments.

TweetBacks

Comments

[Add Comment] [Subscribe to Comments]

Comment 1 written by Rob Brooks-Bilson on 2 March 2005, at 6:22 PM

Aw crap! This changes everything. All bets are off. My world is crashing in around me. The horror, the horror!

Seriously, Ray. Good info here. Thx.
Comment 2 written by John Farrar on 2 March 2005, at 6:29 PM

How about the scope safe issues... wouldn't you do something like this instead?

<cfscript>
function foo() {
var local = structNew();
var x = "apple";
try {
if(x+9) x = 1;
} catch(ANY local.myerror) {
writeOutput(local.myerror.message & "<p>");
}
}
</cfscript>

<cfoutput>
#foo()#
</cfoutput>

Heh... life gets twisted. (I have also learned on "iteration" calls of functions... the "structNew()" can make execution much slower. So this solution is a spare use function.
Comment 3 written by Sean Corfield on 2 March 2005, at 6:57 PM

You obviously didn't try that code John - catch requires a simple variable name.
Comment 4 written by Jeff Coughlin on 2 March 2005, at 6:57 PM

Good catch Ray. I'm curious though. What happens if you use try/catch as cf tags (assuming you tried this in a cffunction tag)?

I'm running out the door at the moment, but maybe I'll try this tonight if someone else hasn't.
Comment 5 written by Arindam Biswas on 3 March 2005, at 8:51 AM

My, my. One learns something new all the time. Great catch that one!
Comment 6 written by Raymond Camden on 3 March 2005, at 8:57 AM

John - you don't have to worry about it at all. Not var scoping the variable is ok in this case since it won't "leak" out at all.
Comment 7 written by Nathan Dintenfass on 4 March 2005, at 11:59 AM

Please tell me that this is, in fact, a bug and not something that is "intended behavior"
Comment 8 written by Raymond Camden on 4 March 2005, at 1:43 PM

I'm not a Java expert, but someone pointed out that he thought it was the same in Java. Ie, you don't have to pre-declare the variable in the catch block. So maybe that is the reasoning.
Comment 9 written by Roland Collins on 4 March 2005, at 1:54 PM

Very interesting . . .

Even if you declare myerror as "java.lang.Exception", it still misbehaves. Instead of the dereference error, you get a NullPointerException.
Comment 10 written by William on 22 March 2006, at 6:01 PM

I don’t understand why you are declaring “myerror” any way? It is being declared in catch.
Comment 11 written by Raymond Camden on 23 March 2006, at 9:02 AM

William, the point is that any declared variable in a UDF needs to be var scoped. (Normally.)