Ugo Cei wrote:
How about this?
} catch (ProcessingException e) { getLogger().debug("Rethrowing exception", e); throw new SAXException(e); }
This is not only useless, it's plain wrong.
why so?
because SAXExceptions must be related to XML and it might be that this ProcessingException was related to e.g. sql operations? And this breaks with the 'IS A' test?
I'm not sure: I think this depends on your understanding of what is the meaning of a SAXException. Its purpose of existence is not to communicate XML related errors, its purpose is to communicate to XML processing components that they should stop doing so since wellformedness of the communicated data (somewhere along the pipe) is not ensured?
would this be your alternative then:
have a SAXWrappingProcessingException subclass that can only wrap a SAXException that should be plainly unwrapped and rethrown in the case that the context allows for it?
} catch (SAXWrappingProcessingException e) {
throw e.getWrappedSAXException();
}
// not catching the ProsessingException will just let it propagate
-marc= (still enthousiastically trying to be enthousiast) -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
