cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26445] - NPE at o.a.xalan.transformer.TransformerImpl.java:1497
Date Tue, 09 Mar 2004 22:07:27 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26445>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=26445

NPE at o.a.xalan.transformer.TransformerImpl.java:1497





------- Additional Comments From joerg.heinicke@gmx.de  2004-03-09 22:07 -------
> Would you be able to propose this change to the Xalan people or open an
> appropriate case there?

So let's CC the Xalan list, hoping anybody from there can comment on this thread.

> I do not agree with "The NPE is a runtime exception, so there is no must
> of handling it.". An NPE should never occur and sometimes it is very helpful
> to handle such exceptions, to deliver some context in an error message (like
> what parameter is set and what is the value - which might give me a starting
> point to blame my style-sheet) and then re-throw the exception. I agree with
> the rest of your comment that this is difficult, as it is another library that
> crashes. But it would be a defensive programming strategy. Sorry for the
> lecture, may be I have worked in QA for too long?

No, your thoughts on "defensive programming" are valid and of course we try to
do this in our codebase. I have for example my problems when developing with
Woody that I also get more or less non-expressive exceptions from JXPath - a
woody specific exception would help in much cases I think.

But what I do not want to do is to catch all possible runtime exceptions in the
external libraries. How shall we guess what happened in your case? So IMO
runtime exceptions must be handled in the libraries they can occur. What we
should do of course is the correct logging of such an exception. Some really
rare cases (this one is not the first one) seem to circumvent our logging.

Mime
View raw message