Runtime: Add TryParse to XDocument

[ilmax]

Hi, this is a RFC issues to request support for a adding a bool TryParse(string text, out XDocument document) method to the XDocument class.

I've searched around the repo but cannot find anything related, so if this is a dupe feel free to close.

Problem:

Sometimes happens that you have to work with XML files that comes from _untrusted_ sources, and you have to ensure that the file is actually well formed XML.

Currently there are some not so nice ways to verify a string is a well formed XML that involves exception handling.

None of the suggested ways looks like a clean solution to a quite common problem (at least IMO).

Please note also that other BCL classes that exposes a Parse(string source) method usually also exposes a bool TryParse(string source, out...) thus adding a TryParse method will make XDocument class somewhat more consistent with other BCL classes.

Suggestion:

add the following method

bool TryParse(string text, out XDocument document)

to XDocument and XElement classes

Question:

Do we need feature parity with XmlDocument classes?
Actually XmlDocument exposes a LoadXml(string xml) so we could add a bool TryLoadXml(string xml, out XmlDocument document) but I really don't like the name and thus if feature parity isn't a must, I would prefer not adding it.

[weshaggard]

We reviewed this and don't fully understand the value of adding a TryParse method in this case. While consistency with other BCL types is somewhat interesting it is much more useful in those cases because you are potentially parsing a lot of them and so there is a performance issue. In this case performance isn't really going to be an issue because the exception cost is tiny compared to the cost of parsing the entire XML document. Also with the Parse methods you will get an XmlException on errors which gives additional information that points you to the parsing error which you wouldn't have in the TryParse cases.

For similar cases the Roslyn APIs don't offer a TryParse method parsing a CS file either because you generally want more context on any errors, but even that maybe overkill for parsing XML documents which is why we have the middle ground of basic information in the XmlException.

Thanks for the issue and writing it up but for these reasons we don't think there is much value in adding a TryParse method to these.

[Crono1981]

@weshaggard,

Aside from convenience, a TryParse method would allow a dev to skip the overhead associated with try / catch blocks and the instantiating of a non-needed XmlException he/she may not even care about.

I too was very surprised to discover that no such method existed. :|

[marcelbeckcmi]

To me personally the answer of @weshaggard makes 0 sense. Imo all ppl out there, using .NET for longer than a half year, are totally aware of the explanations in the first part of @weshaggard´s post . Not handling and not caring about errors in detail is, at least for me in the last 20 years, the MAIN reason, to use a TryParse() variant, if the class provides one.

I think a lot of ppl already came here in the last X years, after looking at the stackoverflow post about it, and go like "oh. there really is no TryParse() on XDocument. strange."

But, ... whatever.