You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Jeff Greif <jg...@alumni.princeton.edu> on 2004/11/01 22:09:12 UTC
The log ate my homework
The public org.apache.xpath.objects.XObject classes have some pitfalls for
the unwary. In particular, some of the public methods have unexpected
behavior which is only documented on the subclasses. For example, suppose
you try this:
XObject homework = XPathAPI.eval(context, xpath, resolver);
if ( ... something indicates a String result is wanted ...) {
return homework.str();
}else ... other cases ...
Later, you may need to do some diagnosis of an unexpected result, so you
insert before the 'if':
log.debug("Evaluation of xpath " + xpath + " on Node "
+ serialize(context) + " yielded the result of type "
+ homework.getTypeString() + " " + homework);
Oops, the log just ate your homework! The result will be different from
what was returned before, except when no nodes were found in the evaluation.
This is because toString() calls str() and for certain subclasses of
XObject, such as XNodeSet, str() side-effects the object, incrementing an
internal iterator and potentially returning a different result each time.
If your XNodeset is of length 1, the second and subsequent calls will
produce the empty string.
I think the documentation could more strongly point up the issue. Since code
that is perturbed by debugging is particularly nasty to debug, it's better
to be able to read about the pitfall than suffer the pointed stakes at the
bottom.
Jeff
Re: The log ate my homework
Posted by Morris Kwan <mk...@ca.ibm.com>.
There is already a bug opened for this problem.
http://nagoya.apache.org/jira/browse/XALANJ-1335
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: mkwan@ca.ibm.com
"Jeff Greif"
<jgreif@alumni.pr
inceton.edu> To
<xa...@xml.apache.org>
11/01/2004 04:09 cc
PM
Subject
The log ate my homework
The public org.apache.xpath.objects.XObject classes have some pitfalls for
the unwary. In particular, some of the public methods have unexpected
behavior which is only documented on the subclasses. For example, suppose
you try this:
XObject homework = XPathAPI.eval(context, xpath, resolver);
if ( ... something indicates a String result is wanted ...) {
return homework.str();
}else ... other cases ...
Later, you may need to do some diagnosis of an unexpected result, so you
insert before the 'if':
log.debug("Evaluation of xpath " + xpath + " on Node "
+ serialize(context) + " yielded the result of type "
+ homework.getTypeString() + " " + homework);
Oops, the log just ate your homework! The result will be different from
what was returned before, except when no nodes were found in the
evaluation.
This is because toString() calls str() and for certain subclasses of
XObject, such as XNodeSet, str() side-effects the object, incrementing an
internal iterator and potentially returning a different result each time.
If your XNodeset is of length 1, the second and subsequent calls will
produce the empty string.
I think the documentation could more strongly point up the issue. Since
code
that is perturbed by debugging is particularly nasty to debug, it's better
to be able to read about the pitfall than suffer the pointed stakes at the
bottom.
Jeff