Check well-formed XML without a try/catch?

耗尽温柔 提交于 2019-11-27 08:51:01

I don't know a way of validating without the exception, but you can change the debugger settings to only break for XmlException if it's unhandled - that should solve your immediate issues, even if the code is still inelegant.

To do this, go to Debug / Exceptions... / Common Language Runtime Exceptions and find System.Xml.XmlException, then make sure only "User-unhandled" is ticked (not Thrown).

Steve,

We had an 3rd party that accidentally sometimes sent us JSON instead of XML. Here is what I implemented:

public static bool IsValidXml(string xmlString)
{
    Regex tagsWithData = new Regex("<\\w+>[^<]+</\\w+>");

    //Light checking
    if (string.IsNullOrEmpty(xmlString) || tagsWithData.IsMatch(xmlString) == false)
    {
        return false;
    }

    try
    {
        XmlDocument xmlDocument = new XmlDocument();
        xmlDocument.LoadXml(xmlString);
        return true;
    }
    catch (Exception e1)
    {
        return false;
    }
}

[TestMethod()]
public void TestValidXml()
{
    string xml = "<result>true</result>";
    Assert.IsTrue(Utility.IsValidXml(xml));
}

[TestMethod()]
public void TestIsNotValidXml()
{
    string json = "{ \"result\": \"true\" }";
    Assert.IsFalse(Utility.IsValidXml(json));
}

That's a reasonable way to do it, except that the IsNullOrEmpty is redundant (LoadXml can figure that out fine). If you do keep IsNullOrEmpty, do if(!string.IsNullOrEmpty(value)).

Basically, though, your debugger is the problem, not the code.

Add the [System.Diagnostics.DebuggerStepThrough] attribute to the IsValidXml method. This suppresses the XmlException from being caught by the debugger, which means you can turn on the catching of first-change exceptions and this particular method will not be debugged.

Caution with using XmlDocument for it possible to load an element along the lines of <0>some text</0> using XmlDocument doc = (XmlDocument)JsonConvert.DeserializeXmlNode(object) without an exception being thrown.

Numeric element names are not valid xml, and in my case an error did not occur until I tried to write the xmlDoc.innerText to an Sql server datatype of xml.

This how I validate now, and an exception gets thrown
XmlDocument tempDoc = XmlDocument)JsonConvert.DeserializeXmlNode(formData.ToString(), "data"); doc.LoadXml(tempDoc.InnerXml);

Shivanath D

The XmlTextReader class is an implementation of XmlReader, and provides a fast, performant parser. It enforces the rules that XML must be well-formed. It is neither a validating nor a non-validating parser since it does not have DTD or schema information. It can read text in blocks, or read characters from a stream.

And an example from another MSDN article to which I have added code to read the whole contents of the XML stream.

string str = "<ROOT>AQID</ROOT>";
XmlTextReader r = new XmlTextReader(new StringReader(str));
try
{
  while (r.Read())
  {
  }
}
finally
{
  r.Close();
}

source: http://bytes.com/topic/c-sharp/answers/261090-check-wellformedness-xml

nickdu

I disagree that the problem is the debugger. In general, for non-exceptional cases, exceptions should be avoided. This means that if someone is looking for a method like IsWellFormed() which returns true/false based on whether the input is well formed XML or not, exceptions should not be thrown within this implementation, regardless of whether they are caught and handled or not.

Exceptions are expensive and they should not be encountered during normal successful execution. An example is writing a method which checks for the existance of a file and using File.Open and catching the exception in the case the file doesn't exist. This would be a poor implementation. Instead File.Exists() should be used (and hopefully the implementation of that does not simply put a try/catch around some method which throws an exception if the file doesn't exist, I'm sure it doesn't).

Just my 2 cents - there are various questions about this around, and most people agree on the "garbage in - garbage out" fact. I don't disagree with that - but personally I found the following quick and dirty solution, especially for the cases where you deal with xml data from 3rd parties which simply do not communicate with you easily.. It doesn't avoid using try/catch - but it uses it with finer granularity, so in cases where the quantity of invalid xml characters is not that big, it helps.. I used XmlTextReader, and its method ReadChars() for each parent element, which is one of the commands that do not do well-formed checks, like ReadInner/OuterXml does. So it's a combination of Read() and ReadChars() when Read() stubmbles upon a parent node. Of course this works because I can do assumption that the basic structure of the XML is okay, but contents (values) of certain nodes can contain special characters that haven't been replaced with &..; equivalent... (I found an article about this somewhere, but can't find the source link at the moment)

My two cents. This was pretty simple and follows some common conventions since it's about parsing...

public bool TryParse(string s, ref XmlDocument result)
{
    try {
        result = new XmlDocument();
        result.LoadXml(s);
        return true;
    } catch (XmlException ex) {
        return false;
    }
}
标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!