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 "Casey, Greg" <GC...@Engage.com> on 2000/07/18 00:29:24 UTC

FW: Xerces-c bug?

Here's my info:
 
Xerces-C version: 1. 2 .0
Platform: Windows NT version 4.00.1381
Microsoft Visual C++ version 6.0
 
The problem:
 
Basically, I'm using the SAX parser and it states that there are two types
of errors: non-fatal and fatal. Also, non-fatal errors shouldn't cause an
exception to be thrown and shouldn't stop the parser. However, I'm finding
that all errors stop the parser and here's why:
 
In the file XMLValidator.cpp, there are three "emitError" methods. Each of
them does the same thing after calling the ErrorReporter:
 
// Bail out if its fatal an we are to give up on the first fatal error
if ((XML4CValid::isValid(toEmit) || XML4CValid::isFatal(toEmit))
&&  fScanner->getExitOnFirstFatal()
&&  !fScanner->getInException())
{
    throw toEmit;
}
 
If you look at the XML4CValid class, you'll find that an error cannot be
both valid and fatal. I guess that's why the programmer uses an OR operator
in this line. However, what this code is saying is that if the error is
valid and we're supposed to exit on our first fatal error, then throw an
exception. 
 
The problem is that even the non-fatal errors are valid errors, so it always
throws an exception regardless of the fatality factor. I think it should be
rewritten like so:
 
// Bail out if its fatal an we are to give up on the first fatal error
if (XML4CValid::isFatal(toEmit)
&&  fScanner->getExitOnFirstFatal()
&&  !fScanner->getInException())
{
    throw toEmit;
}
 
What do you think?
 
-gtc

------------------------------------------------------------
Greg Casey
Software Developer
Engage
gcasey@engage.com <ma...@engage.com> 
 
 

Re: Xerces-c bug?

Posted by Dean Roddey <dr...@charmedquark.com>.
My understanding is that validity errors are fatal errors. Or at least that was my understanding at the time I wrote that. If you aren't validating, you shouldn't get any validity errors. If you are validating, then failure to meet the validity constraint is a fatal error, right?

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


  ----- Original Message ----- 
  From: Casey, Greg 
  To: 'xerces-c-dev@xml.apache.org' 
  Sent: Monday, July 17, 2000 3:29 PM
  Subject: FW: Xerces-c bug?


  Here's my info:
   
  Xerces-C version: 1. 2 .0
  Platform: Windows NT version 4.00.1381
  Microsoft Visual C++ version 6.0
   
  The problem:
   
  Basically, I'm using the SAX parser and it states that there are two types of errors: non-fatal and fatal. Also, non-fatal errors shouldn't cause an exception to be thrown and shouldn't stop the parser. However, I'm finding that all errors stop the parser and here's why:
   
  In the file XMLValidator.cpp, there are three "emitError" methods. Each of them does the same thing after calling the ErrorReporter:
   
  // Bail out if its fatal an we are to give up on the first fatal error
  if ((XML4CValid::isValid(toEmit) || XML4CValid::isFatal(toEmit))
  &&  fScanner->getExitOnFirstFatal()
  &&  !fScanner->getInException())
  {
      throw toEmit;
  }
   
  If you look at the XML4CValid class, you'll find that an error cannot be both valid and fatal. I guess that's why the programmer uses an OR operator in this line. However, what this code is saying is that if the error is valid and we're supposed to exit on our first fatal error, then throw an exception. 
   
  The problem is that even the non-fatal errors are valid errors, so it always throws an exception regardless of the fatality factor. I think it should be rewritten like so:
   
  // Bail out if its fatal an we are to give up on the first fatal error
  if (XML4CValid::isFatal(toEmit)
  &&  fScanner->getExitOnFirstFatal()
  &&  !fScanner->getInException())
  {
      throw toEmit;
  }
   
  What do you think?
   
  -gtc

  ------------------------------------------------------------
  Greg Casey
  Software Developer
  Engage
  gcasey@engage.com