CF7 : Java methods returning 'null' -UndefinedVariableException on assignment - is it a bug?

[PaulH]

well don't have it return a NULL, return something else or simply check if that var isDefined(), setting a cf var to NULL effectively destroys it as far as cf is concerned.

[pmularien]

Thanks for the input, however - this API is used by Java "clients" other than
CF, and in Java, returning a variable with a value of null is perfectly
acceptable. I don't want to have to call the method twice - I guess what I'm
asking is - is there a reason why a null value from a Java method can't simply
set the object to undefined, instead of throwing this bad exception?

[PaulH]

not following. why would you have to call it twice? if that var isn't defined then the method returned a NULL. game over.

[pmularien]

Right. The problem is that the exception occurs on -assignment- of the value
null to the variable. The exception is thrown by the <cfset ... = > tag, and
thus I can never test whether e.g. IsDefined(obj). Make sense?

[PaulH]

i guess the var keyword is causing cf to evaluate that object
prematurely--though i'm not seeing this (in the simple test below) on cf 7.
what version of cf? i recall building a dumbed down java class to produce/test
for nulls and it seemed to work as i expected. i'm at home now, i'll try to dig
out that code and test again when i get into the office tomorrow.

<cfscript>
function z(){
var x=javacast("null","");
if (isDefined("x"))
return true;
else
return false;
}
writeoutput("is x defined? #yesNoFormat(z())#");
</cfscript>

[PaulH]

ah, you're right. when i cracked open that java code i saw i'd built a method
to detect nulls. and i understand why you mean to call that method twice
(sometimes i am a monkey's uncle). does the workaround below make any sense?


import java.lang.Object;

public class nulls {
public final static Object returnNull(){
return null;
}

public final boolean isNull(Object varToTest) {
if (varToTest == null)
return true;
else
return false;
}

}

<!--- round-a-bout --->
<cfscript>
function killMeDead() {
var nullUtil=createObject("java","nulls");
var nullVar=false;
var nulledvar=false;
try {
nullVar=nullUtil.returnNull();
nulledVar=nullVar;
}
catch (Any e) {
nulledVar=true;
}
return nulledVar;
}
writeoutput("did a null kill me? #killMeDead()#");
</cfscript>

[cf.Objective]

What are the circumstances under which the Java method call returns a null, and is it a straight-up "return null;" result?

[pmularien]

I ended up taking a slightly different approach - basically I created a wrapper
function in CF to check for nulls - very trivial:

...
<cffunction name="checkJavaNull" access="public" returntype="any"
output="false" hint="Checks whether a java object is null and returns
appropriately">
<cfargument name="obj" type="any" required="no" hint="The java object">

<cfif IsDefined("arguments.obj")>
<cfreturn arguments.obj/>
<cfelse>
<cfreturn ""/>
</cfif>
</cffunction>
...

Now for any Java call that may return null as a matter of course, I just wrap
it with this method (all the CFCs that are interacting with Java have a common
superclass, so it looks just like a regular CF function call:

...
<cfset var obj = checkJavaNull(javaObj.javaMethodWhichMayReturnNull (...)) />
...


Apparently (as we all know) CF is OK with method arguments being undefined -
so we simply check within the checkJavaNull method whether or not a valid
argument was passed in - if not, it must have been Java null, so just return CF
null, which == "".

Thanks, Paul, for the suggestion of moving the null detection into Java - IMHO
being able to do it in CF is more natural for our CF developers/users, so I
chose to go with a CF solution. This happens on either CF 6.1 or 7 - and it
doesn't seem to matter whether I have the var declaration there or not - that
is - both of these will fail in the same way -

<cfset var obj = willReturnNull(...)/>

vs.

<cfset var obj = ""/>
...
<cfset obj = willReturnNull(...)/>


Hope this solution helps someone else!

[pmularien]

BTW, IMHO this is still a CF bug - I think CF should perform this null check
behind the scenes for us when processing results from any Java method. But
until/if this is fixed within CF, the workaround is fine for us.