Suresh Thalamati wrote:
While doinng buddy testing of xml featuress, I think I gave a wrong
xpath and XALAN throwed assertion to my surprise.
Thanks for buddy testing this, Suresh!
Not sure if it is some setup issue from derby side or XALAN edge
case bug.
Given the nature of the error "Programmer's assertion in getNextStepPos", my
guess is that this is a Xalan-side issue. I could of course be wrong, but the
error message and the stack trace seem to indicate that to me...
But annoying thing is after that query, it gives my favorite errror
"ERROR 40XT0: An internal error was identified by RawStore module."
is there any way to catch these assertions ?
Great catch. The code right now only catches certain Exceptions that could be
thrown by Xalan (or JAXP) according to the APIs. It then wraps those exceptions
in StandardException and re-throws the StandardException. In the example shown
above, the error is some kind of assertion failure, not a normal Exception, and
thus it isn't correctly caught/wrapped. I think the best thing to do is to
change the code to catch "Throwable" instead of Exceptions; that way any
Throwable that is thrown by Xalan--which includes NPEs, the above assertion
error, etc--will be caught, wrapped, and re-thrown. The statement itself will
still fail, but Derby as a whole should still run as normal--i.e. no "ERROR
40XT0" stuff.
I made some quick changes in a local codeline to catch Throwable instead of
Exceptions and that did the trick. The query still failed with this rather odd
assertion failure, but after the failure I could continue to execute other Derby
statements as normal. So that's an improvement.
I'll try to formalize this and post a patch in the next day or two. This seems
like something that should go into 10.2, if possible...
another minor thing I noticed is errors from XALAN or nested as
"ERROR XJ001: Java exception" it might be better to classify these
exception under some different exception name.
When we catch a Xalan error we wrap it using the "newException()" method on
StandardException that takes a Throwable as a parameter. I haven't looked but
apparently that method is what adds the "ERROR XJ001" info. I don't know
offhand how to best change that, but you're right, I think it'd be a good
improvement. That particular change may have to be a post 10.2 change, though...
Thanks again for the feedback,
Army
