Ok, I signed on to the user-c list also.
Suzanne
David N
Bertoni/Cambridge To: [EMAIL PROTECTED]
/IBM cc:
<david_n_bertoni@ Subject: Re: exception classes
us.ibm.com>
03/14/2003 12:06
PM
Please respond to
xalan-dev
Hi Suzanne,
One of the problems with posting questions on the Xalan developer list is
you risk confusing the Java implementation and the C++ implementation.
That's why I suggested you might want to start posting on the Xalan-C user
list.
The answer to your question is we don't have a comprehensive guide to the
various exceptions thrown by Xalan. You might want to grep the code for
the word "catch" to see what some other code does. You should also take a
look at the implementation of the class XalanTransformer, as that is the
basis of our public interface for XSLT.
A quick answer to your question is you can catch the base exception class
XSLException. It has some member functions for default formatting of error
messages.
Dave
Suzanne Dirkers
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
com> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: Re: exception
classes
03/14/2003 08:46
AM
Please respond
to xalan-dev
Hi,
I am talking about trying to give more explicit information on what
an exception that is caught is all about, as in the SimpleXPathAPI sample,
for example, there is a try/catch block where the catch part basically
catches ANY kind of exception and it appears the most the programmer can do
is just say "Exception caught!" but it seems it would be good to be able to
say what kind of exception, or give some kind of clue as to why a
particular API is giving back an exception. For example, if I'm getting an
exception because XPATH doesn't know what my namespace is, it would be nice
to be able to print out "Exception: unresolved namespace prefix urn:" , for
example.
Suzanne
Joseph
Kesselman/Watson/ To:
[EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
Subject: Re: exception
classes
03/14/2003 10:46
AM
Please respond to
xalan-dev
The XSLT language doesn't really have any concept of exceptions; it can
neither catch them nor throw them. The closest you can come is using
<xsl:message> with terminate="yes", which will produce an error and --
unless you've overridden this behavior with a custom error handler -- shut
down the XSLT processor.
If that doesn't answer your question, could you be more explicit about
what you're trying to do (or avoid)?
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"may'ron DaroQbe'chugh vaj bIrIQbej" ("Put down the squeezebox and nobody
gets hurt.")
