Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to continue parsing after Error::EndEventMismatch #513

Closed
moy2010 opened this issue Nov 27, 2022 · 2 comments · Fixed by #677
Closed

Allow to continue parsing after Error::EndEventMismatch #513

moy2010 opened this issue Nov 27, 2022 · 2 comments · Fixed by #677

Comments

@moy2010
Copy link

moy2010 commented Nov 27, 2022

I'm trying to parse a Netscape bookmark file which has unclosed tags (i.e. <DL>), and for this I'm explicitly ignoring the EndEventMismatch error during the parsing:

match reader.read_event() {
    Err(e) => match e {
        QuickXmlError::EndEventMismatch { expected: _, found: _ } => (),

The issue is that an Eof event immediately follows this, which causes that the reader stops parsing the rest of the document.

I couldn't find in the documentation if this behaviour is expected, hence why I'm opening the issue.

@Mingun
Copy link
Collaborator

Mingun commented Nov 27, 2022

I've never think about this way of reading events, but it seems to a good candidate to support. PR is welcome.

Current way to achive the same is to disable reporting mismathed ends. Unfortunately, the example that shows how you can disable this only for a part of document, is bug-prone. If you do that, the Start event name won't be popped out from internal stack of unclosed events and you'll get a wrong EndEventMismatch error after closing the first surrounding tag:

<some-tag>
  <event>
    <!-- You decided to .check_end_names(false) after seeing "<event>" -->
    ...
  </event>
  <!-- You decided to .check_end_names(true) after seeing "</event>" -->
</some-tag><!-- EndEventMismatch { expected "event", found: "some-tag" } -->

@moy2010
Copy link
Author

moy2010 commented Nov 27, 2022

Ah, thanks for pointing to that method, Mingun! In the case of parsing the Netscape bookmark file there's no need to re-enable the check for end-names since there's no surrounding tag.

As you said, it would be very error prone if that was the case and the desired behaviour was that of toggling on and off the check for end-names.

@Mingun Mingun changed the title Unexpected Eof event due to unclosed tags Allow to continue parsing after Error::EndEventMismatch Nov 28, 2022
Mingun added a commit to Mingun/quick-xml that referenced this issue Nov 4, 2023
Fixed:
    check_end_names::true_::mismatched_tags

failures:
    dashes_in_comments
Mingun added a commit that referenced this issue Nov 5, 2023
Introduce `Config` struct that holds parser configuration and implement #513
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants