[jdom-interest] String index out of range in Beta 7

Cyrus Kalbrener ckalbrener at nistevo.com
Tue Jul 17 07:13:13 PDT 2001

This is great, except that it doesn't solve the problem: valid XML docs are
failing to parse.  In this particular case, it seems to be that the lack of
a PUBLIC entry in the DOCTYPE declaration.  Sometimes other documents fail
to parse and altering a single character in the value of any element will
make it work.

It's weird, it's unpredictable, and I need to find a fix for it.  I have
tried several versions of the Xerces parser.  Is there another parser that
might yield better results?

-----Original Message-----
From: Jason Hunter [mailto:jhunter at collab.net]
Sent: Monday, July 16, 2001 12:44 PM
To: Alex Rosen
Cc: 'Cyrus Kalbrener'; jdom-interest at jdom.org
Subject: Re: [jdom-interest] String index out of range in Beta 7

Alex Rosen wrote:
> That line in Xerces 1.2.0 is just a re-throw of the real underlying
> exception in a SAXException. Unfortunately our JDOMException doesn't
> dive more than one level deep when printing out stack traces, so the
> *real* cause is lost.
> I'll submit a patch so that JDOMException will also print out the root
> stack trace for SAXExceptions. Should I check for other common nested
> exceptions too? The comment in this bug
> http://developer.java.sun.com/developer/bugParade/bugs/4209652.html
> mentions:
>     java.sql.SQLException
>     java.lang.reflect.InvocationTargetException
>     java.lang.ExceptionInInitializerError
>     java.rmi.RemoteException
>     javax.naming.NamingException
> I can check for all of these, but if we still need to maintain JDK 1.1
> compatibility, I need to figure out if any of these are new for 1.2 and
> skip them.

I think the patch is a great idea.  All are core JDK 1.1 except
NamingException which isn't part of the core even in JDK 1.2. 
ServletException is another exception that can have a root cause.  It'd
be good to handle both, but I don't want to require having the servlet
library in the classpath in order to build or a JNDI library.  Would
reflection solve the problem?  If only there was some overlap!

getCause()           // JDK 1.4 standard naming convention
getRootCause()       // ServletException, NamingException
getNextException()   // SQLException
getTargetException() // InvocationTargetException
getException()       // ExceptionInInitializerError
public detail        // RemoteException

Perhaps we could use strong typing for those exceptions in the JDK 1.1
core: SQLE, ITE, EIIE, RE; and we use reflection for the futures: SE,
NE, future Throwable.  Then reflection only has to handle getRootCause()
and getCause() which are general enough that other application-specific
classes might use them too.

It's interesting, btw, that JDOMException is the only exception class
that prints its nested exceptions by default when you call

> In the mean time, when you print out the stack trace, you should be able
> to do this yourself: call JDOMException.getCause(), and if that's a
> SAXException, call SAXException.getException(), and print out that stack
> trace. Or, can you try using the latest Xerces? 1.2.0 is pretty old.

Yes, as a workaround just print the nested-nested exception's trace.


More information about the jdom-interest mailing list