Re: [saxdotnet-devel] ErrorHandler arguments

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
>> I must have missed this. Could you explain it again?
> 
> 
> Something like this could be placed in your object heirarchy. One could 
> also very easily create a tee-like observer pattern and some 
> ExceptionHandler class. This could be designed into a subclass 
> ContentHandler and used from within callbacks
> 
> public FooContentHandler : ContentHandler {
> 
>   public ExceptionHandler exceptionHandler;
> 
>   public void startElement(...) {
>     // some code happens, we need to throw an exception
>     exceptionHandler.Handle(new FooException());
>   }
> }
> 
> public ExceptionHandler {
> 
>   public void Handle(Exception e)
>     throws SAXException {
>     if (....) {
> 
>     } else
>      throw new SAXException(e);
>   }
> }

Yes, this is definitely possible. Although I like the name
of ErrorHandler better, since passing error information does
not have to be based on using Exception objects.

This was already discussed (sort of) on xml-dev,
but I really would prefer to use the existing API.
The API above would be similar to any (proprietary)
way of exchanging information between those content
handler that you have control over, and your application.

The question is, do we need to standardize on this in SAX?
As far as all the other interfaces are concerned, they form
a contract for an IXmlReader implementation, so standardizing
them is good.

But I don't think we should make too many restrictions on
how content handler implementations and the application communicate.
This could not even be tested for conformance.

What about a validating IXmlFilter implementation?
Well, it must conform to the IXmlreader contract, and therefore
should call back on IErrorHandler.

> Now these are just some random ideas thrown out after a long night in 
> the rain so I could be way off. Also, in the back of my mind I am 
> wondering about how Java handles that exception class if not actually 
> thrown. 

I guess the GC disposes of them.

> On top of that I saw in some of your examples that you handled a 
> FileNotFound exception in a slightly different way (it seems that IO 
> exceptions would need a slightly different pattern anyway because they 
> are not treated strictly as SAXParseExceptions to begin with). But all 
> of leads me to think that you can have your cake and eat it too...
> 
>> It would be a simple documentation change.
> 
> 
> I like simple...

What do you think of this:

For the purpose of the SAX API we define "parsing" as
generating a sequence of call-backs on SAX handler interfaces
that represent a well-formed XML document. This applies even
if no actual XML document is being processed.

Karl