[EMAIL PROTECTED] wrote:
3. There are multiple places where exceptions are caught for other
functionality, so maybe there is more code duplication we can remove.
I'm wondering if the best way to model all of this is a base and child
class, or something more complex like:
XalanTransformerBase
/ \
XalanTransformer XalanTransformerEx
I've starting experimenting along these lines. The methods look like this:
void XalanTransformerBase::doBaseTransform(...) // Exceptions uncaught
int XalanTransformer::doTransform(...)
{
try
{
doBaseTransform(...)
}
catch ...
}
One of the big annoyances, that I'm sure you've noticed, is the presence
of redundant exception handling code. In my own code, I have a huge
macro like this to avoid the code duplication:
#define CATCHXALANEXCEPTION(exceptionHandler) \
catch (XSLTProcessorException & processorException) \
{ \
exceptionHandler(processorException); \
} \
...
And every method that calls a Xalan method looks like this:
try
{
}
CATCHXALANEXCEPTION(thisclass::handler)
Of course there has to be a handler overload for every exception type.
Does anyone have any objections to such a big macro exception handler?
Cheers,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
