views:

200

answers:

2

hey guys, I've got this scenario:

while (reader.Read())
{
    if (reader.NodeType == XmlNodeType.Element && reader.Name == itemElementName)
    {
        XElement item = null;
        try
        {
            item = XElement.ReadFrom(reader) as XElement;
        }
        catch (XmlException ex)
        {
           //log line number and stuff from XmlException class  
        }
    }
}

In the above loop I'm transforming a certain node (itemElementName) into an XElement.

Some nodes will be good XML and will go into an XElement, however, some will not.

In the CATCH, I'd like to not only catch the standard XmlException stuff... I'd also like to catch an extract of the current Xml and a string.

However, if I do any kind of READ operation on the node before I pass it to the XElement, it moves the reader forward.

How can get a "snapshot" of the contents of the OuterXml of the reader without interfering with it's position?

+1  A: 

Don't use any 'Read' operation on the reader- as you've discovered, this advances it. Use calls to properties such as reader.HasValue and reader.Value to inspect the contents. Look up 'XmlReader' in the object browser, there's quite a few properties you can read.

Edit: I don't think there's an easy way of simply getting the XML, possibly because the current node may not be valid XML on it's own, such as an XmlWhiteSpace, XmlText node or even an XmlAttribute.

Flynn1179
thanks flynn... so for my purposes I'm hoping to get an extract of invalid xml before the error is thrown when trying to create the XElement. Are you saying that's impossible?
andy
Probably not impossible; I'm kicking myself for not remembering this before, but if you call `reader.ReadSubtree()`, it creates a whole new XmlReader that starts at wherever `reader` is; you can read that all you like without affecting your original `reader`. Not 100% sure how you'd use this in your situation, but it looks like it's probably the way to go.
Flynn1179
+2  A: 

Actually ReadSubtree will return a reader which "wraps" the original reader. So reading through the new one will end up advancing the original one as well. You must consider XmlReader as a forward only reader, it simply can't go back. As for your scenario, instead of trying to remember part of the XML you can ask the reader for the position in the input file. Just cast it to IXmlLineInfo interface, it has methods to return line and position. Using this you could remember some starting position (before the element in question) and then the end position of the error. And then read that part from the intput file as a plain text.

Vitek Karas MSFT
yes, perfect, thank you, that's exactly what was happening. thanks for the explanation!
andy
Ah.. I totally misinterpreted the point of ReadSubTree then.. sorry about that. To be honest though, it doesn't make this obvious from the documentation in object browser, but the MSDN page makes it clearer.
Flynn1179
I just went back and had another look at the code I've got that uses it; it actually stops reading altogether after it's finished with the subtree, so I never noticed it had advanced the original reader too.
Flynn1179