cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Q] Returning XSP errors on incorrect use of a logicsheet...
Date Mon, 22 Jul 2002 20:49:57 GMT
> From: Per Kreipke [mailto:per@onclave.com]
> 
> > > Vadim Gritsenko wrote:
> > > ...
> > > > Here is the hint. I guess these two files should be patched:
> > > > xml-cocoon203\src\java\org\apache\cocoon\components\xslt\
> > > > XSLTProcessorImpl.java
> > > >
xml-cocoon203\src\java\org\apache\cocoon\util\TraxErrorHandler.java
> > >
> > > :-|
> > >
> > > This is roughly the 10000000002nd time that these get patched for
wrong
> > > error reporting.
> > > Ugh :-S

:)


> > I don't think the error is actually _in_ there. The TraxErrorHandler
is
> > correctly handling and reporting the errors.

But it does not throw an exception!


> > IMHO the problem is that the
> > exception is never propagated (or caught) in the caller during
> > the transform step.

Possible bug in Xalan?


> > Possibly because the XSLT step is being swallowed by the threaded
> > transformation (note: can't find that particular code).
> >
> > Subsequently, the error shows that shows up in the browser ("Error
> > compilling foo.xsp: Line 0, column 0: error: java.io.IEException:
> > read error
> > 1 error") makes perfect sense: the file doesn't exist because the
> > Transformer never completed.
> >
> > The solution is to trap XSLT errors when generating the Java code
for the
> > XSP. I'm looking at it but another hint would probably speed things
up ;-)
> 
> 
> In particular:
> 
> ProgramGeneratorImpl.generateResource(...) calls
> markupLagnuage.generateCode(...);
> 
> without any try block or checking the return code (maybe it returns a
null
> length string?).
> 
> So, whatever MarkupLanguage subclass it's calling isn't generating an
> exception that would get propagated out of generateResource(). If it
did,
> everything might be ok.
> 
> So I recant my earlier statement, the error could be where Vadim said
it
> was: in the TraxErrorHandler.  Onward.

Exactly. When TraxErrorHandler finds an error, it should throw an error
which should be propagated to the initiator of transformation:

http://java.sun.com/xml/jaxp/dist/1.1/docs/api/javax/xml/transform/Error
Listener.html:
  Throws:
    TransformerException - if the application chooses to
    discontinue the transformation.


I think TraxErrorHandler can buffer all warnings and errors and throw an
exception on fatalError. (What is terminate="yes": error or fatal
error?).


Vadim


> Per



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message