When the function works properly (without runtime error) it will return a
node set, the original SQL Document. When there is a runtime error, i.e.
an SQL Error, the function saves the error information and returns DTM.NULL.
The stylesheet can now wrap the function call in an <xsl:if > statement testing
for NOT of the function. If there is a runtime error, the body if the
<XSL:IF> statement will execute. The error information can later be
retrieved using the getError function. The problem we have is that the
XSL:IF will end up calling the AxisWalker#isDocOrdered method and
in FilteredExprWalker, that method will fail because the document or
the m_Expr variable is null.
Give me a call if you think we can more effectively discuss this over the
phone.
-JohnG
[EMAIL PROTECTED] wrote:
> John, I think we might have a disconnect here. Is the function returning a
> node or a node-set?
>
> If it is just returning a node, then the fix is easy, I think.
>
> -scott
>
>
> John Gentilin
> <gentijo@eyecatch To: [EMAIL PROTECTED]
> ing.com> cc: [EMAIL PROTECTED],
>xalan <[EMAIL PROTECTED]>
> Subject: Re: (SQL Extension / NPE
>issue) Re: Help, waiting on an answer
> 03/28/2002 01:31
> PM
> Please respond to
> xalan-dev
>
>
>
> We could/should make FilterExprWalker more robust but I get the
> feeling that if we tape off this leak, it will just spring up somewhere
> else. Would one or more of the solutions below make more sense.
>
> 1) Create an object that will product an empty document statically ??
> return this document instead of DTM.NULL.
>
> 2) Have the extension handler detect a return of DTM.NULL and
> translate that to an empty document
>
> 3) Create a set of exception classes. If the base class is thrown then
> translate that to an empty document. From there build a framework
> that will allow the extension handler to return a special "Error"
> document
> using the exception framework to maintain a basic structure. i.e. Design
> so that a fixed set of XPath statements will always work on an Extension
> Error.
>
> Previously my goal was to create an easy way to allow the stylesheet
> designer
> to detect a simple error. If I just threw an exception, that would
> terminate the
> transformation. My first version just returned a special "Error Document"
> but
> I was finding that a lot of time was used to execute two "apply-templates"
> one
> for the good document and one for the bad. Returning a NULL or empty
> document
> allowed the quicker <xsl:if test > to be used and it was far easier to
> implement
> contextual information in the error handling.
>
> JohnG
>
> [EMAIL PROTECTED] wrote:
>
> > > It seems to me that returning DTM.NULL is a valid return
> > > for an extension function, A) depending on the situation, you may not
> be
> > able to
> > > construct an empty document, B) In the DOM spec,
> > Element@getElementsByTagName
> > > a return of null is valid if there are no matching elements. and C) the
> > function
> > > FilterExprWalker#isDocOrdred should really test of m_Expr != null
> before
> > > executing the method.
> >
> > There is no NULL in XPath, so dealing with null is somewhat problematic.
> > For a nodeset, the equivalent of null is an empty nodeset. So a function
> > that promises to return a node-set should return a node-set. A null is
> > translated in XNull, and should really be dealt with like another
> external
> > opaque object, in that we don't know what to do with it in the context of
> a
> > node-set.
> >
> > I don't have any strong objection to making a filter expression handle a
> > null return from an extension for the sake of robustness. But I don't
> > think that it is a given.
> >
> > -scott
> >
> >
> > John Gentilin
> > <gentijo@eyecatch To:
> [EMAIL PROTECTED], xalan <[EMAIL PROTECTED]>
> > ing.com> cc: Scott Boag
> <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > Subject: (SQL Extension /
> NPE issue) Re: Help, waiting on an answer
> > 03/27/2002 08:05
> > PM
> >
> >
> >
> > Scott,
> >
> > Glad to hear that you are felling better. I was assuming that SQL mods
> > (besides the storm I started with the inclusion of 3rd party jars) just
> > were
> > not making it to the top of the list.
> >
> > The problem at hand.
> >
> > If the SQL Extension runs into a problem, it records the error and
> returns
> > DTM.NULL. This should allow you to test on the return nodeset then
> > do error handling, in the stylesheet, based on the getError() Document
> >
> > for example:.
> > <xsl:if test="not(sql:connect($db, $cinfo))" >
> > <xsl:message>Error Connecting to the Database</xsl:message>
> > <xsl:copy-of select="sql:getError($db)/ext-error" />
> > </xsl:if>
> >
> > The worked fine on all the previous versions of Xalan until somewhere
> > around
> > D12/D14.
> >
> > The problem is that FilterExprWalker only checks for a null m_Expr in
> some
> > of
> > the methods. I changed it so if m_Expr was null then execute
> super.method
> > ()
> > since the default behavior of AxisWalker seems to be the correct
> behavior.
> >
> > I had changed it originally but never checked it in because I did not get
> > an
> > solid answer for the question, "Can a Extension function return DTM.NULL
> > or does it have to return an empty document. Someone commented that the
> > spec is not clear in this area and since this was a behavioral type
> change
> > in an area that I have not spent tons of time in, I was waiting for a
> > response
> > before proceeding. It seems to me that returning DTM.NULL is a valid
> return
> > for an extension function, A) depending on the situation, you may not be
> > able to
> > construct an empty document, B) In the DOM spec,
> > Element@getElementsByTagName
> > a return of null is valid if there are no matching elements. and C) the
> > function
> > FilterExprWalker#isDocOrdred should really test of m_Expr != null before
> > executing the method. My $.02.
> >
> > Regards
> > John G
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > Hi John. I was sick in January and part of February, and so missed
> > *lots*
> > > of mail. I'm still not caught up... I don't know if I ever will be.
> > >
> > > FilterExprWalker (which changed a lot with my last check-in, BTW) (and
> > now
> > > FilterExprIteratorSimple#executeFilterExpr) doesn't do any magic with
> the
> > > return from it's expression. So returning null would be a bad idea
> > > (sorry). An extension meant to return a null nodeset should return an
> > > empty DTMIterator or the like.
> > >
> > > I guess we could change this, so that null would be an acceptable
> return
> > > val. Do you think it should be changed?
> > >
> > > -scott
> > >
> > >
> > > John Gentilin
> > > <gentijo@eyecatch To: Scott Boag
> > <[EMAIL PROTECTED]>
> > > ing.com> cc:
> > > Subject: Help, waiting
> on
> > an answer
> > > 02/02/2002 03:46
> > > PM
> > >
> > >
> > >
> > > Scott,
> > >
> > > In the last few weeks there were a few discussions on Iterators
> > > and empty sets returned as null from extension functions. The only
> > > thing I got feedback on was the legality of including InstantDB. Looks
> > > like I created a little scuttle that got the lawyers all excited.
> > > Anyway,
> > > I would like to put the finishing touches on the SQL extensions but
> > > I needed an answer on how empty sets were to be handled. It falls
> > > into one of two categories. 1) Empty sets can not be returned as a
> > > null. or 2) null is a valid return, and the Iterator in question needs
> > > to test for null. I believe you were CC'ed on most conversations
> > > and I read in the group that you were currently working on the
> > > iterators so I though I would rattle your cage.
> > >
> > > Hope all is going well.
> > >
> > > Regards
> > > JohnG
--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
