You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Sc...@lotus.com on 2001/01/26 20:08:10 UTC
Re: cvs commit: xml-xalan/java/src/org/apache/xalan/processor
TransformerFactoryImpl.java
Costin, these seem OK, though if fatalError is called and no exception is
thrown, all bets are certainly off. Note that the documentation contract
for these states that these functions never return null.
> The spec is not clear about what
> should happen if an ErrorListener is set, and fatalError is called
An ErrorListener is always set, and should normally throw an exception for
fatalError. Probably the documentation should be updated to be clear about
this.
-scott
costin@apache
.org To: xml-xalan-cvs@apache.org
cc: (bcc: Scott Boag/CAM/Lotus)
01/26/01 Subject: cvs commit: xml-xalan/java/src/org/apache/xalan/processor
01:48 PM TransformerFactoryImpl.java
Please
respond to
xalan-dev
costin 01/01/26 10:48:51
Modified: java/src/org/apache/xalan/processor
TransformerFactoryImpl.java
Log:
Fix the fix for ErrorListener. The spec is not clear about what
should happen if an ErrorListener is set, and fatalError is called -
it does mention that "ErrorListener callbacks should be called _instead_
of throwing exception" ( in ErrorListener's comments ), but what happens
when fatalError returns ?
The current code returns null ( since creating the object - Transformer,
etc - failed, and we can't throw exceptions ).
This fix does some extra checks for NPE, in this case. It shouldn't be
a big performance problem, constructing the transformer is a
very expensive operation any way.
Scott - please review the changes, maybe you have a better idea to deal
with ErrorListener.
Revision Changes Path
1.22 +12 -2
xml-xalan/java/src/org/apache/xalan/processor/TransformerFactoryImpl.java
Index: TransformerFactoryImpl.java
===================================================================
RCS file:
/home/cvs/xml-xalan/java/src/org/apache/xalan/processor/TransformerFactoryImpl.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- TransformerFactoryImpl.java 2001/01/24 19:54:12
1.21
+++ TransformerFactoryImpl.java 2001/01/26 18:48:49
1.22
@@ -483,7 +483,8 @@
{
Templates templates = newTemplates(src);
-
+ if( templates==null ) return null;
+
return newXMLFilter(templates);
}
@@ -533,6 +534,7 @@
{
Templates templates = newTemplates(src);
+ if( templates==null ) return null;
return newTransformerHandler(templates);
}
@@ -629,7 +631,15 @@
throws TransformerConfigurationException
{
try {
- return newTemplates(source).newTransformer();
+ Templates tmpl=newTemplates( source );
+ /* this can happen if an ErrorListener is present and it doesn't
+ throw any exception in fatalError.
+ The spec says: "a Transformer must use this interface
+ instead of throwing an exception" - the newTemplates() does
+ that, and returns null.
+ */
+ if( tmpl==null ) return null;
+ return tmpl.newTransformer();
} catch( TransformerConfigurationException ex ) {
if( m_errorListener != null ) {
try {
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-cvs-help@xml.apache.org
Re: cvs commit: xml-xalan/java/src/org/apache/xalan/processor
TransformerFactoryImpl.java
Posted by co...@eng.sun.com.
> Costin, these seem OK, though if fatalError is called and no exception is
> thrown, all bets are certainly off. Note that the documentation contract
> for these states that these functions never return null.
>
> > The spec is not clear about what
> > should happen if an ErrorListener is set, and fatalError is called
>
> An ErrorListener is always set, and should normally throw an exception for
> fatalError. Probably the documentation should be updated to be clear about
> this.
I agree - but as long as the spec doesn't require fatalError to throw
exception and requires the transformer "to use this interface _instead_ of
throwing an exception", the test case is valid.
I'll ask Rajiv if he can add the clarification.
Costin