RE: How to get the error code during SAX parse?

[Dean Roddey]

I don’t work on it anymore, so you’d need to take it up with Tinny and crew now.   On your second point, any exception that doesn’t derive from XMLException will not get caught and will propagate back to the caller as is. I’m not sure these days whether DOM or SAX exceptions are derived from XMLException or not. I don’t think that was the original design, which is why that particular domain is hard coded, since it was only expected to catch internal scanner exceptions.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   I suspect you might need a new api to pass through the error domain as well.  The existing emitError functions all hard code the error domain. Otherwise a mapping of the error code between the domains is required ... (I think the error code from XMLException and/or DOMException is in a different domain to that of XMLUni::fgXMLErrDomain as hard coded in emitError - not sure tho, would have to bury my head in the code a bit more).   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 01:55 PM Please respond to xerces-c-dev                 To:        [EMAIL PROTECTED]         cc:                 Subject:        RE: How to get the error code during SAX parse? What really should be happening is this:     emitError                (                   excToCatch.getCode()                    , excToCatch.getType()                    , excToCatch.getMessage()                );   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 8:30 PM To: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   scanner code (XMLScanner:            else if (excToCatch.getErrorType() >= XMLErrorReporter::ErrType_Fatal)                emitError                (                    XMLErrs::XMLException_Fatal                // <-- here - no translation from exeToCatch.                    , excToCatch.getType()                    , excToCatch.getMessage()                ); The error code from excToCatch is discarded and completely lost before you get to where error is called (error is called from within the emitError function). Maybe emitError should be enhanced (new version of) to include the error domain etc so it can all be passed through to the error handler.   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 01:11 PM Please respond to xerces-c-dev                To:        [EMAIL PROTECTED]        cc:                Subject:        RE: How to get the error code during SAX parse? I wrote the core parser, and though it's been a while since I've been into it, I'm pretty dang sure that the internal error callbacks provide the error codes. Here is the method for the internal error callback:   virtual void error    (        const   unsigned int        errCode        , const XMLCh* const        errDomain        , const ErrTypes            type        , const XMLCh* const        errorText        , const XMLCh* const        systemId        , const XMLCh* const        publicId        , const unsigned int        lineNum        , const unsigned int        colNum    ) = 0;   The first parameter is the error code.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 7:34 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   We seem to be at cross purposes here ... terminology: what I say is the parser (DOM and SAX) call 'wrapper'. XMLScanner call 'scanner'. The DOM 'wrapper' and the SAX 'wrapper' both call/use XMLScanner - understood. If the file does not exist, the 'scanner' traps the exception itself, translates (masks) the error code, then calls the 'wrapper's error handler function.  So the way the things are at present is that the 'wrapper' is not given the error code for the error that caused the parse to fail so subclassing the 'wrapper' does not help - because all the 'wrapper' is told is XMLErrs::XMLException_Fatal. So what I am saying is even if the SAX api were to be extended to provide access to the error code, the error code the SAX 'wrapper' can provide to the caller is somewhat limited.   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 12:00 PM Please respond to xerces-c-dev               To:        [EMAIL PROTECTED]       cc:               Subject:        RE: How to get the error code during SAX parse? You are missing the point. The 'parser' is not the SAXParser class. The parser itself (the scanner is what it is called) is inside of the various DOMParser, SAXParser, etc… Those are just wrappers around the scanner. You can, as a worst case fallback, always just override say the DOMParser class, which itself implements the scanner's callback's and plugs itself into the scanner. It then gets error callbacks (and other kinds of callbacks) from the scanner, which it then turns around and passes out through whatever APIs available for a particular type of interface, e.g. SAX, SAX2, DOM.   The internal callbacks from the scanner provide all of the information that is possibly available. The fact that some of that information gets dropped on the way out via a particular API doesn't mean that the data isn't available, it just means that perhaps the API you are using to get the data out doesn't provide a means to get all of the data out.   But, if you derive from the DOMParser class, for instance, and override the virtual method that it uses to get error callbacks, you can get the internal callbacks from the scanner, which has all of the available info in it. You can look at that info, and then pass it on the parent class for regular processing.   I'm not saying you really need to do that in this case, since it might just be that you don't understand the SAX2 API well enough to know how it gives you errors. But, when there is no other way to get certain info, you can always do it this way.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   The error handler is not given the actual error code, only one of XMLErrs::XMLException_Fatal XMLErrs::XMLException_Error XMLErrs::XMLException_Warning and hence my issue ... Is there good reason to 'mask' the actual error that occured?  If not maybe it can be resolved by a simple change to XMLScanner::scanDocument so that the actual error code is passed through to the error handler.   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 11:35 AM Please respond to xerces-c-dev              To:        [EMAIL PROTECTED]      cc:              Subject:        RE: How to get the error code during SAX parse? Oh ok, I forgot that there was a change a while back to get the 'file not found' stuff into the block that reports via the error handler. But the error handler does report the error codes. If the SAX2 specification doesn't provide for that error code to be passed on to the client app, then I guess that's just the way it is. Its not a problem with Xerces, but just with the error callback interface of SAX2. As I said, I've not looked at that interface, so I can't say.   If that is the case, you can still do it. Just provide your own derivative of the SAX2 parser, and override the error callback on the parser object, looking at the raw error callback info, then passing it back to the underlying SAX2 parser for normal processing. I don't know if that's really necessary, since I've not looked at the SAX2 interfaces, and perhaps you just missing something. But that's always a way to get to the raw parser callbacks.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:44 PM To: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   I am not sure what you mean.  XMLScanner traps the exception when the target file does not  exist (for example).  This means that the caller (eg DOMCount) does not get told the file does not exist - only that 'there was an error' via the call back. There is no difference in the behaviour the caller sees if there error was due to file not existing or document being malformed in terms of whether or not an exception is thrown or the callback is called.   In other words: - 'fundamental errors with finding the source data' are reported via the call back 'as parsing errors' if I understand what you are saying. - in DOMCount the catches around the call to parse documents will only catch something if the code was changed to try parsing another document whilst a parse is in progress or similar. In the case that the target files does not exist the caller has no way of knowing what the actual error was without parsing the error message (which is a bit ugly) ... Are you implying that the exception handling in XMLScanner::scanDocument should actually be removed/altered to allow these 'fundamental' errors to be thrown back to the caller?   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 10:13 AM Please respond to xerces-c-dev             To:        [EMAIL PROTECTED]     cc:             Subject:        RE: How to get the error code during SAX parse? As I said, exceptions are not used to report parsing errors, only fundamental errors with finding the source data, so the catch after the parse is irrelevant for parsing errors. Look at the error handler code for the DOMPrint and DOMCount examples.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 4:30 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   But I'm saying none of the parsers don't supply the information I'd like (ie the actual parsing error that occurred) because the underlying scanner which is used by both DOM and SAX parsers throws the error away ... See XMLScanner::scanDocument - the exception handling that is invoked (if file does not exist for example).   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 09:23 AM Please respond to xerces-c-dev            To:        [EMAIL PROTECTED]    cc:            Subject:        RE: How to get the error code during SAX parse? I can't speak to the SAX2 part, since I've not looked at that variant. The parser itself does provide the information you want, but if the SAX2 specification (which the Xerces team does not define) doesn't provide a way to pass it on, then there's not much the parser can do about it.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 4:13 PM To: [EMAIL PROTECTED] Subject: RE: How to get the error code during SAX parse?   Can we get some enlightenment on this (for the dummies!). When you say the pluggable error call backs, do you mean the things you set by calling SAX2XMLReader::setErrorHandler or SAXParser::setErrorHandler? If so, then these are passed a SAXParseException object which does not have an error code. If not, which example should we look at? >From previous discussions, even if the SAXParseException object contained an error code it would only be one of               XMLErrs::XMLException_Fatal               XMLErrs::XMLException_Error               XMLErrs::XMLException_Warning because XMLScanner::scanDocument basically chucks away the actual error. So, to get the actual error code that occurred during a parse you have to hack the Xerces code base ... Would it make sense if the scanner passed through the actual error code to XMLScanner::emitError and thence to its error reporter?  Then each of the error reporters for each parser can take the appropriate action (and one could then simply subclass the relevant parser and overload the error function to trap the actual error code). To me there is a bit of an issue in that it is not easy to take programatic action according to the parser failure (eg take action depending if document was well formed but not valid versus malformed versus file does not exist). What do people think? Am I missing something?   Dean Roddey <[EMAIL PROTECTED]> 25/09/2002 08:27 AM Please respond to xerces-c-dev           To:        [EMAIL PROTECTED]   cc:           Subject:        RE: How to get the error code during SAX parse? Errors are not reported via the exceptions, they are reported via pluggable error callbacks. An exception can only report one error, because it unwinds the stack. The callbacks allow the parser to continue through more than one error (if you tell it that's ok to do.) Look at the sample programs, which clearly show how this is done.   ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com   -----Original Message----- From: Scot Nielsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 3:09 PM To: 'Xerces-Dev (E-mail)' Subject: How to get the error code during SAX parse?   Can someone enlighten me please? There's no error code value in the SaxParseException class...   Are all error codes for internal use only?   Many thanks, Scot Nielsen