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 Simon Kitching <si...@ecnetwork.co.nz> on 2002/10/09 02:07:52 UTC

RE: How to throw custom defined exceptions, warnings from xsl pag e?

Hi Prakash,

I have to do exactly the same thing as you.

Unfortunately, Xalan has some problems in this area, for which I am
intending to submit some patches when I finally dig myself out from the
pile of work I have at the moment.

I hope that one of the suggestions below helps..

-- option 1: xsl:message

In a stylesheet, you can use:

<xsl:message terminate="yes"> Error X has occurred </xsl:message>

This will cause the ErrorListener associated with the current
Transformer object to be called as follows:
(a) the info method of the error listener is called, with the message
body text specified in the stylesheet, then
(b) the error method of the error listener is called with the message
"stylesheet directed termination".

The default ErrorListener's info/warn methods prints messages to stdout,
then returns (which causes the stylesheet to continue). The error/fatal
methods throw a TransformerException which ends up being thrown out of
the Transformer.transform method, where your code can pick it up.

You will probably want to set a custom ErrorListener on the transformer
before doing the transform, in order to redirect the error messages to
somewhere other than stdout (or is it stderr), or (as suggested below)
cache it for later retrieval.

The problem is that the exception that is thrown by
Transformer.transform just contains the message "Stylesheet directed
termination"; the actual message body of the xsl:message tag is not
contained in this exception. What I therefore do is have an
ErrorListener which caches the INFO level exception; when I get a
TransformerException from the Transformer.transform method, I then get
the "real" message from the ErrorListener. This isn't 100% reliable, as
if something else reports an INFO message there can be confusion.
However it works in practice.

I am intending to create a patch which attaches the xsl:message body to
the exception thrown to avoid this roundabout solution; I can't see any
problem with this change. Comments/opinions anyone?

Note also the following bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7357

Due to this bug, if you implement a custom ErrorListener, make sure that
the error/fatal methods generate messages which start with "fatal" or
your xsl processing will not terminate as expected.

-- option 2: a custom extension tag to replace xsl:message

I happen to have some extension elements already being used from my
stylesheet, so I ended up adding another <myprefix:error> extension
which basically implements the patch I suggested above. I won't provide
this code, as it is currently mixed in with all my other stuff, and
anyway the "proper" solution I think is to patch xsl:message.


Regards,

Simon


On Tue, 2002-10-08 at 21:04, Prakash Sridharan wrote:
> Hi Simon,
> 
> I am giving a scenario in which I want to throw custom defined exceptions.  
> 
> The input xml looks like this,
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <person>
> 	<name>P</name>
> 	<age>12</age>
> 	<sex>m</sex>
> </person>
> 
> I am validating the data in the above xml using xsl.
> Some of the validations are,
> 1.  Age should be greater than 18
> 2.  sex should be "m" or "f"
> 
> If the above conditions are not met, I want to throw some exceptions or
> warnings 
> from the xsl.  After rendering, I shoud be able to access all the exceptions
> and 
> warnings from my java program where I am calling this xsl transformation.
> 
> The xsl looks like this,
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> 	<xsl:output method="xml" indent="yes"/>
> 	<xsl:template match="* | /">
> 		<xsl:copy>
> 			<xsl:apply-templates/>
> 		</xsl:copy>
> 	</xsl:template>
> 	<xsl:template match="age">
> 		<xsl:choose>
> 			<xsl:when test="number(.) &gt; 18">
> 				<xsl:copy-of select="."/>
> 			</xsl:when>
> 			<xsl:otherwise>
> 				<!-- throw exception here -->
> 			</xsl:otherwise>
> 		</xsl:choose>
> 	</xsl:template>
> 	<xsl:template match="text() | @*">
> 		<xsl:copy-of select="."/>
> 	</xsl:template>
> </xsl:stylesheet>
> 
> Can you help me in this?
> 
> Thank you,
> Prakash
> 
> -----Original Message-----
> From: Simon Kitching [mailto:simon@ecnetwork.co.nz]
> Sent: Tuesday, October 08, 2002 2:31 AM
> To: Prakash Sridharan
> Cc: xalan-j-users@xml.apache.org
> Subject: Re: How to throw custom defined exceptions, warnings from xsl
> page?
> 
> 
> Hi Prakash,
> 
> Can you provide some more details about what you are trying to do?
> 
> Are you using standard xsl? In this case, what do you mean by "custom
> defined exceptions"? Do you just mean generating your own error
> messages? If this is the case, you can use <xsl:message> together with a
> custom ErrorListener class.
> 
> Are you using some custom extension tags or functions, and want to
> generate errors/exceptions from these? In this case, I can provide you
> with some example code as I am doing this myself.
> 
> Cheers,
> 
> Simon
> 
> On Tue, 2002-10-08 at 05:43, Prakash Sridharan wrote:
> > Hi all,
> >  
> > In my project, I am doing the data validation in an xml through using xsl.
> > I want to throw some
> > custom defined exceptions and warnings from xsl page while rendering based
> > on the validations.  
> > Can anybody help me in doing this?
> >  
> > Thank you,
> > Prakash
> 



RE: How to throw custom defined exceptions, warnings from xsl page?

Posted by Joseph Kesselman <ke...@us.ibm.com>.
I took a quick look, and the TransformerException thrown by
        <xsl:message terminate="yes"> Error X has occurred </xsl:message>
could be made to include the text of the user-supplied message; that's a 
fairly simple change to ElemMessage.java (and possibly to the error 
resources, to do this "the right way" via variable substitution in the 
message rather than by simple string concatenation).

Can anyone think of a reason _not_ to make that change, outside of the 
fact that it may require we update a testcase and might require that some 
internationalization files be updated before they see the additional text?

______________________________________
Joe Kesselman  / IBM Research