You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Christian Aberger <Ch...@Aberger.at> on 2001/03/23 13:55:02 UTC
Exception chaos in Xalan-C
Hi,
I would like to show you a part of my code:
try {
bOK = ProcessAction(m_strAction.c_str(), dwRet);
} catch(const XSLException& e) {
bOK = ReportError(e);
} catch(XMLException& exml) {
bOK = ReportError(exml);
} catch (const DOM_DOMException& e2) {
bOK = ReportError(e2);
} catch(SAXException& esax) {
bOK = ReportError(esax);
} catch(XalanDOMException& exalandom) {
bOK = ReportError(exalandom);
} catch(...) {
m_strErrorMessage = "fatal error processing stylesheet";
bOK = false;
}
Isn't it really cumbersome for an application programmer to code all those
different types of exceptions everytime when Xalan is called ? Same lot of
catches in the samples (I mean those that are done properly, like in
TestXSLT). I don't even talk about how long it took me to find out what
types of exceptions there are, and chances are good that I missed some. Are
you sure that even inside the Xalan code itself all catch handlers are in
place where they should, so that no memory leaks are left?
All I want to have, when things go wrong, is a simple error message. Ouch,
what a lot of hacking to get it! Wouldn't it be nice to derive all
exceptions in Xalan (and Xerces) from logic_error defined in <stdexcept>?
This could propably save thousands of lines of code of Xalan users, and
maybe the same amount of working hours searching why and where an exception
escaped and left a memory leak etc. All one has to do then is a
catch(logic_error& e) in that case. If one needs more detail, OK the
existing catch handlers can be used (an left in existing code).
wfR ChrisA
RE: Exception chaos in Xalan-C
Posted by Matt Leinhos <ma...@granularity.net>.
I agree with Peter and Christian - there are too many exception classes to
deal with. As a new xalan user, I find my C++ code to be ugly and
cumbersome as far as exception handling goes. What I would really like to
see is something like:
class XMLExceptionBase {
virtual string getMessage() = 0;
virtual string getType() = 0;
...
}
and for all *Exception classes to be derived from the XMLExceptionBase
class shown above.
I'm glad to see that others have noticed this as well.
Matt Leinhos
On Mon, 26 Mar 2001, Peter Murphy wrote:
> > -----Original Message-----
> > From: Christian Aberger [mailto:Christian@Aberger.at]
> >
> > Hi,
> > I would like to show you a part of my code:
> >
> > try {
> > bOK = ProcessAction(m_strAction.c_str(), dwRet);
> > } catch(const XSLException& e) {
> > bOK = ReportError(e);
> > }
>
>
> Etc...
>
> >
> >
> > Isn't it really cumbersome for an application programmer to code all those
> > different types of exceptions everytime when Xalan is called ?
>
> It's also intimidating for new programmers trying to get a handle on Xalan.
>
>
> > Same lot of catches in the samples (I mean those that are done properly,
> like in
> > TestXSLT). I don't even talk about how long it took me to find out what
> > types of exceptions there are, and chances are good that I missed
> > some.
>
> To be fair to the Xalan developers, the profusion of exception classes
> really starts in Xerces. The hierarchy in Xerces appears to be:
>
> --------------------------
> SAXException
> \-----SAXNotSupportedException
> \-----SAXNotRecognizedException
> \-----SAXParseException
>
> DOM_DOMException
> \-----DOM_RangeException
>
> EndOfEntityException
>
> XMLException
> \-----EmptyStackException
> \-----ArrayIndexOutOfBoundsException
> \-----IOException
> \-----IllegalArgumentException
> \-----InvalidCastException
> \-----NoDefTranscoderException
> \-----NoSuchElementException
> \-----NullPointerException
> \-----XMLPlatformUtilsException
> \-----RuntimeException
> \-----TranscodingException
> \-----UTFDataFormatException
> \-----UnexpectedEOFException
> \-----UnsupportedEncodingException
> \-----NetAccessorException
> \-----MalformedURLException
> ----------------------------
>
> Leaving alone EndOfEntityException (which is meant to be internal to
> Xerces), that's three class hierarchies of exceptions to be caught by the
> budding Xalan developer.
>
> Then there's two more exceptions hierarchies native to Xalan:
>
> ----------------------------
> XSLException
> \-----DOMSupportException
> \-----InvalidURIException
> \-----XPathException
> \-----XObjectException
> \-----XObjectInvalidCastException
> \-----XPathExpressionException
> \-----InvalidOpCodeException
> \-----InvalidArgumentCountException
> \-----InvalidArgumentException
> \-----InvalidRelativeTokenPosition
> \-----FoundIndex
> \-----XPathExceptionFunctionNotAvailable
> \-----XPathParserException
> \-----UnrepresentableCharacterException
> \-----XalanOutputStreamException
> \-----XalanFileOutputStreamOpenException
> \-----XalanFileOutputStreamWriteException
> \-----UnknownEncodingException
> \-----UnsupportedEncodingException
> \-----TranscoderInternalFailureException
> \-----TranscodingException
> \-----XalanStdOutputStreamWriteException
> \-----XMLSupportException
> \-----XSLTProcessorException
> \-----ElemMessageTerminateException
> \-----InvalidStackContextException
>
> XalanDOMException
> \-----XercesDOMException
> ------------------
>
> The situation concerns me:
>
> 1. Like Christian, I agree that 5 exception hierarchies is too much.
> Reducing this would be a good thing; it would make the life of Xalan
> programmers so much easier.
> 2. Reducing the number of classes in each hierarchy would also be a good
> thing... if it can be done without hampering the current functionality. Some
> of the more specific XPathException classes (which refer to message and
> XalanNode) could be kept. Others (like DOMSupportException) could be culled.
>
> If the only difference between that and its base is the situation in which
> its called, then use an opcode to distinguish them.
>
> (That, BTW, is a real problem with the XMLException classes. There's a
> profusion of classes whose only difference is their name. Different opcodes
> for different situations sounds like a go - and it wouldn't confuse newbies
> as much)
>
> > All I want to have, when things go wrong, is a simple error message. Ouch,
> > what a lot of hacking to get it! Wouldn't it be nice to derive all
> > exceptions in Xalan (and Xerces) from logic_error defined in <stdexcept>?
>
> It sounds like a good idea to derive all exceptions from a common source.
> However, I thought Xerces didn't use STL, so logic_error wouldn't be
> legitimate. (And logic_error uses "string" internally, when XalanDOMString
> would be a better choice for messaging.)
>
> A better choice would be something like this:
>
> class XALAN_EXPORT XalanException
> {
> int iExceptOpcode;
> XalanDOMString message;
>
> XalanException(int iExceptCode, XalanDOMString& message = 0);
> ...};
>
> With a list of numerical codes to distinguish the exception cases:
>
> #define XPATH_EXCEPTION_VAL 12000
> #define XPATH_INVALID_OPCODE 12001
> #define XPATH_INVALID_ARGUMENT_COUNT 12002
>
> Etc..
>
> >
> > wfR ChrisA
> >
>
> What are other people's thoughts on the matter?
>
> Regards,
> Peter.
>
>
RE: Exception chaos in Xalan-C
Posted by Peter Murphy <pe...@fast.fujitsu.com.au>.
> -----Original Message-----
> From: Christian Aberger [mailto:Christian@Aberger.at]
>
> Hi,
> I would like to show you a part of my code:
>
> try {
> bOK = ProcessAction(m_strAction.c_str(), dwRet);
> } catch(const XSLException& e) {
> bOK = ReportError(e);
> }
Etc...
>
>
> Isn't it really cumbersome for an application programmer to code all those
> different types of exceptions everytime when Xalan is called ?
It's also intimidating for new programmers trying to get a handle on Xalan.
> Same lot of catches in the samples (I mean those that are done properly,
like in
> TestXSLT). I don't even talk about how long it took me to find out what
> types of exceptions there are, and chances are good that I missed
> some.
To be fair to the Xalan developers, the profusion of exception classes
really starts in Xerces. The hierarchy in Xerces appears to be:
--------------------------
SAXException
\-----SAXNotSupportedException
\-----SAXNotRecognizedException
\-----SAXParseException
DOM_DOMException
\-----DOM_RangeException
EndOfEntityException
XMLException
\-----EmptyStackException
\-----ArrayIndexOutOfBoundsException
\-----IOException
\-----IllegalArgumentException
\-----InvalidCastException
\-----NoDefTranscoderException
\-----NoSuchElementException
\-----NullPointerException
\-----XMLPlatformUtilsException
\-----RuntimeException
\-----TranscodingException
\-----UTFDataFormatException
\-----UnexpectedEOFException
\-----UnsupportedEncodingException
\-----NetAccessorException
\-----MalformedURLException
----------------------------
Leaving alone EndOfEntityException (which is meant to be internal to
Xerces), that's three class hierarchies of exceptions to be caught by the
budding Xalan developer.
Then there's two more exceptions hierarchies native to Xalan:
----------------------------
XSLException
\-----DOMSupportException
\-----InvalidURIException
\-----XPathException
\-----XObjectException
\-----XObjectInvalidCastException
\-----XPathExpressionException
\-----InvalidOpCodeException
\-----InvalidArgumentCountException
\-----InvalidArgumentException
\-----InvalidRelativeTokenPosition
\-----FoundIndex
\-----XPathExceptionFunctionNotAvailable
\-----XPathParserException
\-----UnrepresentableCharacterException
\-----XalanOutputStreamException
\-----XalanFileOutputStreamOpenException
\-----XalanFileOutputStreamWriteException
\-----UnknownEncodingException
\-----UnsupportedEncodingException
\-----TranscoderInternalFailureException
\-----TranscodingException
\-----XalanStdOutputStreamWriteException
\-----XMLSupportException
\-----XSLTProcessorException
\-----ElemMessageTerminateException
\-----InvalidStackContextException
XalanDOMException
\-----XercesDOMException
------------------
The situation concerns me:
1. Like Christian, I agree that 5 exception hierarchies is too much.
Reducing this would be a good thing; it would make the life of Xalan
programmers so much easier.
2. Reducing the number of classes in each hierarchy would also be a good
thing... if it can be done without hampering the current functionality. Some
of the more specific XPathException classes (which refer to message and
XalanNode) could be kept. Others (like DOMSupportException) could be culled.
If the only difference between that and its base is the situation in which
its called, then use an opcode to distinguish them.
(That, BTW, is a real problem with the XMLException classes. There's a
profusion of classes whose only difference is their name. Different opcodes
for different situations sounds like a go - and it wouldn't confuse newbies
as much)
> All I want to have, when things go wrong, is a simple error message. Ouch,
> what a lot of hacking to get it! Wouldn't it be nice to derive all
> exceptions in Xalan (and Xerces) from logic_error defined in <stdexcept>?
It sounds like a good idea to derive all exceptions from a common source.
However, I thought Xerces didn't use STL, so logic_error wouldn't be
legitimate. (And logic_error uses "string" internally, when XalanDOMString
would be a better choice for messaging.)
A better choice would be something like this:
class XALAN_EXPORT XalanException
{
int iExceptOpcode;
XalanDOMString message;
XalanException(int iExceptCode, XalanDOMString& message = 0);
...};
With a list of numerical codes to distinguish the exception cases:
#define XPATH_EXCEPTION_VAL 12000
#define XPATH_INVALID_OPCODE 12001
#define XPATH_INVALID_ARGUMENT_COUNT 12002
Etc..
>
> wfR ChrisA
>
What are other people's thoughts on the matter?
Regards,
Peter.