saxdotnet-devel

[saxdotnet-devel] ErrorHandler arguments

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

On xml-dev there is a thread called "[xml-dev] SAXException, checked, buy why?".
The problem that came up is what to do when trying to pass recoverable
errors to the application? Alan Gutierrez thinks one is not allowed to use
error handler call-backs, but I think that maybe this is just a result
of underspecification. In any case, the objects passed to the error
call-backs are SAXParseException objects in Java, and ParseError objects
in SAX for .NET.

I am thinking we should rename the class from ParseError to SAXError,
as errors from application code (as you might have in your content handlers)
are not really parse errors, and you should still be allowed to pass
them to the error handlers, to avoid throwing an exception.

However, all members of ParseError (or SAXParseException ) are geared towards
errors that can occur when parsing an XML document (publicId, SystemId,
Line/ColumnNumber, etc.).

So, what to do?
Should we stick with the limitation that only parse errors can
be reported to the error handlers? Is that not rather limiting?

Karl

Re: [saxdotnet-devel] ErrorHandler arguments

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

Reply to self:


Karl Waclawek wrote:
 > On xml-dev there is a thread called "[xml-dev] SAXException, checked, buy why?".
 > The problem that came up is what to do when trying to pass recoverable
 > errors to the application? Alan Gutierrez thinks one is not allowed to use
 > error handler call-backs, but I think that maybe this is just a result
 > of underspecification. In any case, the objects passed to the error
 > call-backs are SAXParseException objects in Java, and ParseError objects
 > in SAX for .NET.
 >
 > I am thinking we should rename the class from ParseError to SAXError,
 > as errors from application code (as you might have in your content handlers)
 > are not really parse errors, and you should still be allowed to pass
 > them to the error handlers, to avoid throwing an exception.
 >
 > However, all members of ParseError (or SAXParseException ) are geared towards
 > errors that can occur when parsing an XML document (publicId, SystemId,
 > Line/ColumnNumber, etc.).

There is also the problem that SaxParseException has ParseError as member.
So, renaming ParseError gives cascading problems.

 > So, what to do?
 > Should we stick with the limitation that only parse errors can
 > be reported to the error handlers? Is that not rather limiting?

Maybe the right approach is to simply docoument a broader definition
of "parsing". One could say that in the context of SAX,

  "parsing" denotes any form of generating a stream of
   ContentHandler/LexicalHandler events that correspond
   to a well-formed XML document.

With that definition, a "parse" error could also be
an error in the underlying event generation when it
is not XML document based.

So, with giving "parsing" a broader definition
we also give ParseError a broader meaning.

Karl

Re: [saxdotnet-devel] ErrorHandler arguments

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

Jeff Rafter wrote:
> Karl,
> 
> What did you think about my idea for a supplemental Exception handler 
> interface? This could be grafted on without much change to the 
> fundamentals of the API.

I must have missed this. Could you explain it again?

> Otherwise, might I suggest making ParseError 
> descend from SAXError and making SAXError more generic. Then you could 
> simply use "is" or a cast to get the more complete parse error 
> information when applicable.

If you look at SAX more closely, a lot of stuff that
now is based on the assumption of "parsing an XML document"
could be re-defined more generically in terms of a well-formed event sequence.
That could be a lot of work.

For instance: ParseError.Throw() has this code:
   throw new SaxParseException(this).
So, if we change to SAXError, we should first make "Throw()"
a virtual method and add it to SAXError where it throws a SaxExcpetion.
Then we need to add a SAXError member to SaxException and and a corresponding
constructor. We have to remove it from SAXParseException (as it already exists
in the base class) and change its constructor.
Then we need to override ParseError.Throw().
Then we have to modify the ParseErrorImpl class accordingly.
And then we still haven't covered all areas where "parsing"
should be generalized.

Yes, I could introduce a SAXError class, but what if we
just document that "parsing" really does not mean that
there has to be an underlying XML document? Any well-formed
event stream is "parsing".
Then we could leave ParseError and even SaxParseException as is.
The Locator related fields in ParseError (and SaxParseException)
are alread optional (they can return null or -1), even in Java.

It would be a simple documentation change.

Karl

Re: [saxdotnet-devel] ErrorHandler arguments

[Jeff R. <li...@je...>]

> 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);
   }
}

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. 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...

Jeff

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

Re: [saxdotnet-devel] ErrorHandler arguments

[Jeff R. <li...@je...>]

> 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.

I can agree with that-- it would be good to couch it in such wording 
though with the statement that we know what SAX Processing is and the 
difference between an XML Processor and Application [1] proper are... 
also, it should be noted (maybe in an example) that in the case of 
something like a CSV parser that generates SAX events line number and 
column number are still useful concepts. When not useful they should be 
-1 and the entity should be (dare I say it?) null...

[1] http://www.w3.org/TR/REC-xml/#dt-xml-proc

Otherwsie, sounds good.

Jeff

Re: [saxdotnet-devel] ErrorHandler arguments

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

Jeff Rafter wrote:
>> 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.
> 
> 
> I can agree with that-- it would be good to couch it in such wording 
> though with the statement that we know what SAX Processing is and the 
> difference between an XML Processor and Application [1] proper are... 
> also, it should be noted (maybe in an example) that in the case of 
> something like a CSV parser that generates SAX events line number and 
> column number are still useful concepts. When not useful they should be 
> -1 and the entity should be (dare I say it?) null...
> 
> [1] http://www.w3.org/TR/REC-xml/#dt-xml-proc

Would you mind making such additions/corrections?
You already seem to know what should be added.
I can do the CVS stuff, to save you time, as there are already
lots of changes in CVS that you would have to check out first.

:-)

Karl