Re: [saxdotnet-devel] Discussion Status 2

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

Jeff Rafter wrote:

>> However, I think I mentioned that RPC is not a common SAX use case.
> 
> 
> I agree, it is not common. I think that when we have that documentation 
> around end document, if we include information about this, we need to 
> explain it clearly (as you did above). Also, I think we need to be 
> explicit about what happens in the case of a user generated exception in 
> a callback (i.e., EndDocument is *still* called).

This is what I have in CVS currently as doc for EndDocument():

     /// <summary>See <see 
href="http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html#endDocument()">
     /// ContentHandler.endDocument</see> on www.saxproject.org.</summary>
     /// <remarks>Differences to Java:
     /// <list type="bullet">
     ///   <item>Stricter about when to call: <c>EndDocument</c> <b>must</b> be called by the
     ///     SAX event producer exactly once as the last event in a SAX event stream initiated
     ///     by a <see cref="IContentHandler.StartDocument"/> call, regardless of any exceptional
     ///     or error situation encountered. Depending on the call communication mechanism, however,
     ///     this is no guarantee that the SAX event consumer will also receive that call.</item>
     /// </list></remarks>


>> I am not sure I understand you fully.
> 
> 
> Well, I was imagining the case where there was a two-gig element name, 
> or two-gig (count) of attributes on an element. We cannot pass the 
> information back clearly... maybe a specialized exception, or something 
> similar to an API FatalError would be useful at that point... so that 
> the cause is clearly identified. Again, this is not something for this 
> release. I just feel as though there are things that we could do to fix 
> this...

Normally, overflow situations are already handled by the runtime system.
What is it we should do over and above that?

Karl