XMLReader skip current element

[Alex]

For example, i have some part of XML file.

<AppSettings>
<Object ClassVersion="1 .0.0.0" Type="AppSettin gs">
<Fields>
<Field Name="App_ID" Type="System.In t32">
<Value>
<int>-1</int>
</Value>
</Field>
<Field Name="AppDate Type="System.Da teTime">
<Value>
<dateTime>200 7-05-25T00:00:00</dateTime>
</Value>
</Field>
<Field Name="AppFileNa me" Type="System.St ring">
<Value>
<string>TEST 03222007.daf</string>
</Value>
</Field>
<Field Name="AppVersio n" Type="System.St ring">
<Value>
<string>1.0.3.3 </string>
</Value>
</Field>
<Field Name="_ClassVer sion" Type="System.St ring">
<Value>
<string>1.0.0.0 </string>
</Value>
</Field>
</Fields>
</Object>
</AppSettings>

As you can see, its corrupted, because AppDate doesn't gave second ".
I am getting exception when reader.MoveToCo ntent (after i read App_ID)
this all are in try..catch section...
and after that i am receiving smth like string fieldname == "AppDate
Type=";
I can't understand, how i can jump to AppFileName and skip corrupted
AppDate ?
so, how in catch section i can jump to next element ? (during
application's work, i dont know what is the name of next element)

Thanks

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nn owslpianmk.comw rote:

On Tue, 05 Jun 2007 12:47:18 -0700, Jon Skeet [C# MVP] <sk***@pobox.co m>
wrote:

It depends on quite how broken you make it.

If you miss off a semi-colon or have a random extra character like "+"
between statements, it's still syntactically invalid, but it recovers
quickly. An extra closing brace certainly confuses it though, yes.

I suppose "recovers" is in the eye of the beholder. What I see when one
leaves off a semi-colon is that the end of the statement where the
semi-colon was expected is flagged. However, the only reason it can do
that is that it is apparent upon seeing the first thing that doesn't make
sense in that statement (ie, the next statement) where the error is.

But I don't really see that the editor has "recovered" . It is simply
pointing out the first place it has detected a problem.

It recovers to the extent that it's able to find errors later on, and
you can still use Intellisense etc.

For example, take this code:

using System;

public class Test
{
static void Main()
{
int x = 5
int y = 10;

Console.WriteLi ne("Hello");
}
}

If you type another "Console." underneath the current call to
Console.WriteLi ne, VS (2005 at least) offers Intellisense.

It's hard for me to judge exactly how well VS does as opposed to
resharper, but if you change Console.WriteLi ne to Console.Foo, I
certainly get some feedback that Foo isn't a valid member of Console.

Just as the
compiler won't compile a file even though it could usually correctly infer
the correct location of the semicolon, it's not really like the VS editor
has judged the remainder of the file correct and accurate. In fact, it
gives up on a variety of automatic stuff once it's stumbled (for example,
I've lost count of the number of times that I don't get Intellisense
feedback because of a localized compiler-type error in my source code).

You should try Eclipse some time - it will compile (in some cases, at
least) syntactically invalid code, generating code which throws an
exception when it's got to somewhere that the compilation broke. Not
terribly handy, but quite cute.

Compilers, code editors, and XML editors alike can all make inferences
about what the input data *should* look like, and try to produce correct
behavior based on those inferences. But my experience (granted, limited
in the case of XML editors, but not so limited in other areas) is that if
the input data does not comply exactly with what's expected, the user is
simply told "this data is bad...I'm not going any further until you fix
it".

Certainly things are more limited after an error, but there's often
still *some* functionality available. If I find the time I might see
what a few XML editors do past an error - whether they still
automatically close tags, find further errors etc. Certainly the VS
2005 XML editor was able to automatically close the "blech" tag in the
below XML, despite the previous error:

<?xml version="1.0" encoding="utf-8" ?>
<foo>
<bar>
<baz text="Hello otherText="Ther e"/>

<blech></blech>
</bar>
</foo>

Also if you change </blechto </blech2it notices that as a second
error.
--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Tue, 05 Jun 2007 13:40:01 -0700, Jon Skeet [C# MVP] <sk***@pobox.co m>
wrote:

[...]
You should try Eclipse some time - it will compile (in some cases, at
least) syntactically invalid code, generating code which throws an
exception when it's got to somewhere that the compilation broke. Not
terribly handy, but quite cute.

Well, sure. I can appreciate "cute". :) But as you say, not terribly
handy. Likewise, just how handy would it be to just skip over an invalid
section of XML, when you have no idea what the overall effect of doing so
would be? Just because the remaining XML can be parsed, that doesn't mean
that it can be *used* without the part that was erroneous.

[...] Certainly the VS
2005 XML editor was able to automatically close the "blech" tag in the
below XML, despite the previous error:

I certainly agree that it *can* be done. I just am not convinced it makes
sense to bother writing the code to do so. It does seem to me that in an
editor, where the user is actively modifying the data, it makes more sense
to put the effort in, but even there I wouldn't necessarily insist on it
(even in VS there are limits to what it can recover from, and frankly it
only handles the simplest situations). I expect it's something you see in
editors that are intended to be feature-laden, considered "heavy-duty"
(that's certainly how I'd describe VS).

In a situation where the data is static though, I don't see the use in
recovering. You never know when the data that was in error was critical
to the use of the larger XML document. Just because you can successfully
parse the rest of the document doesn't mean you should, just as just
because a compiler could make an assumption about where to insert a
missing semi-colon doesn't mean it should.

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nn owslpianmk.comw rote:

[...]
You should try Eclipse some time - it will compile (in some cases, at
least) syntactically invalid code, generating code which throws an
exception when it's got to somewhere that the compilation broke. Not
terribly handy, but quite cute.

Well, sure. I can appreciate "cute". :) But as you say, not terribly
handy. Likewise, just how handy would it be to just skip over an invalid
section of XML, when you have no idea what the overall effect of doing so
would be? Just because the remaining XML can be parsed, that doesn't mean
that it can be *used* without the part that was erroneous.

On the other hand, if I open an invalid XML file it's nice to know
whether there's just one error or whether the whole thing is pooched.

[...] Certainly the VS
2005 XML editor was able to automatically close the "blech" tag in the
below XML, despite the previous error:

I certainly agree that it *can* be done. I just am not convinced it makes
sense to bother writing the code to do so. It does seem to me that in an
editor, where the user is actively modifying the data, it makes more sense
to put the effort in, but even there I wouldn't necessarily insist on it
(even in VS there are limits to what it can recover from, and frankly it
only handles the simplest situations). I expect it's something you see in
editors that are intended to be feature-laden, considered "heavy-duty"
(that's certainly how I'd describe VS).

Agreed in the last bit - and I'm *certainly* not suggesting that the OP
should try to recover.

In a situation where the data is static though, I don't see the use in
recovering. You never know when the data that was in error was critical
to the use of the larger XML document. Just because you can successfully
parse the rest of the document doesn't mean you should, just as just
because a compiler could make an assumption about where to insert a
missing semi-colon doesn't mean it should.

Oh absolutely. I was only talking about editors, where it can be handy
to be able to show more than the first error.

Even with static document reading, it *may* be useful to bomb out with
an error which has a good stab at working out where all the error parts
are, rather than just the first one. That's not the same as really
trying to recover though.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Tue, 05 Jun 2007 15:00:04 -0700, Jon Skeet [C# MVP] <sk***@pobox.co m>
wrote:

On the other hand, if I open an invalid XML file it's nice to know
whether there's just one error or whether the whole thing is pooched.

Sure, I agree. If you're using an editor, that would be a nice feature to
have. But that still doesn't mean it would be a ubiquitous feature in all
XML editors (though I can see how it might appear in advanced editors).

[...]
Even with static document reading, it *may* be useful to bomb out with
an error which has a good stab at working out where all the error parts
are, rather than just the first one. That's not the same as really
trying to recover though.

Nope. :)

If I wanted to provide feedback as to a place to look for the error, I
would inform the user where the last place in the file I had valid data.
That's not really the same as trying to do anything fancy with figuring
out the erroneous part though. All it requires is keep track of how far
into the file you got before you failed to generate new valid data.

It's the parsing bad data that I think is normally going to be outside the
scope of typical software. Sorry if I seem to have taken this thread off
on a tangent. I just got set off by the statement that an XML editor
*has* to handle errors. An XML editor *could* in fact just display the
text beyond the error and tell the user "I'm not going to help you with
this until you fix it". :)

Pete