You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Simon Rowland <sr...@gmail.com> on 2007/02/04 17:40:49 UTC

DOMParser XInclude processor - how to propagate xi exceptions??

Hi All,

As mentioned before I am writing an XInclude module which is fast 
approaching readiness. However, I have hit a snag with error handling, 
and would appreciate any thoughts anyone has on how best to implement it.

Basically, the first instance of xi functionality will be a feature that 
can be set on a DOMParser.

The code calling the DOMParser will have optionally passed the DOMParser 
an errorHandler that can receive and process DOMExceptions which can be 
warnings and fatal errors. The client code should also catch 
DOMExceptions and XMLExceptions that may be thrown during parsing.

The xi module needs to notify the client (the client of the DOMParser 
that is) of resource errors (warnings) and fatal errors (fatal).

The xi module could extend DOMException and thus use the standard error 
handlers or throw the exception to report its problems. This seems wrong 
to me since DOMException is pretty tightly specified and doesn't have xi 
provison:

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-17189187

Other modules in xerces c simply extend the generic XMLException and 
throw that. My gut feelig is that xi should do the same, thus creating a 
XMLXIncludeException subclass of XMLException and throwing that when the 
xinclude processor encounters a Fatal Error. The spec 
http://www.w3.org/TR/xinclude/ doesn't give any details, it merely 
stipulates that processing should stop once a Fatal Error is encountered.

Note that the XMLException route still does not cover reporting the 
warnings, such as resource errors, which may not be fatal but which the 
client may need to be made aware of. To make this work, the user could 
specify a second errorHandler that is capable of receiving XMLExceptions 
and passing this second errorHandler to the Parser for forwarding to the 
xi processor.

Any advice would be gratefully received on this, I am still hoping I 
have missed something basic which means there is clean and simple 
solution to this!
Thanks in advance, Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org


Re: DOMParser XInclude processor - how to propagate xi exceptions??

Posted by Simon Rowland <sr...@gmail.com>.
Alberto Massari wrote:
> Hi Simon,
> sorry for not answering you before...
> For reporting an error you can make the XInclude module accept a pointer 
> to the XMLErrorReporter interface that every parser implements (the same 
> used by the XMLScanner module to report errors to the parsers); then the 
> parser will take care to build the DOMException/SAXException that better 
> suits the caller.
> 
> Alberto
> 
That looks perfect - thanks a lot again Alberto! I'll get this sorted in 
the next couple of days. :)

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org


Re: DOMParser XInclude processor - how to propagate xi exceptions??

Posted by Alberto Massari <am...@datadirect.com>.
Hi Simon,
sorry for not answering you before...
For reporting an error you can make the XInclude module accept a 
pointer to the XMLErrorReporter interface that every parser 
implements (the same used by the XMLScanner module to report errors 
to the parsers); then the parser will take care to build the 
DOMException/SAXException that better suits the caller.

Alberto

At 16.40 04/02/2007 +0000, Simon Rowland wrote:
>Hi All,
>
>As mentioned before I am writing an XInclude module which is fast 
>approaching readiness. However, I have hit a snag with error 
>handling, and would appreciate any thoughts anyone has on how best 
>to implement it.
>
>Basically, the first instance of xi functionality will be a feature 
>that can be set on a DOMParser.
>
>The code calling the DOMParser will have optionally passed the 
>DOMParser an errorHandler that can receive and process DOMExceptions 
>which can be warnings and fatal errors. The client code should also 
>catch DOMExceptions and XMLExceptions that may be thrown during parsing.
>
>The xi module needs to notify the client (the client of the 
>DOMParser that is) of resource errors (warnings) and fatal errors (fatal).
>
>The xi module could extend DOMException and thus use the standard 
>error handlers or throw the exception to report its problems. This 
>seems wrong to me since DOMException is pretty tightly specified and 
>doesn't have xi provison:
>
>http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-17189187
>
>Other modules in xerces c simply extend the generic XMLException and 
>throw that. My gut feelig is that xi should do the same, thus 
>creating a XMLXIncludeException subclass of XMLException and 
>throwing that when the xinclude processor encounters a Fatal Error. 
>The spec http://www.w3.org/TR/xinclude/ doesn't give any details, it 
>merely stipulates that processing should stop once a Fatal Error is 
>encountered.
>
>Note that the XMLException route still does not cover reporting the 
>warnings, such as resource errors, which may not be fatal but which 
>the client may need to be made aware of. To make this work, the user 
>could specify a second errorHandler that is capable of receiving 
>XMLExceptions and passing this second errorHandler to the Parser for 
>forwarding to the xi processor.
>
>Any advice would be gratefully received on this, I am still hoping I 
>have missed something basic which means there is clean and simple 
>solution to this!
>Thanks in advance, Simon
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
>For additional commands, e-mail: c-dev-help@xerces.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org