Runtime: Agregar TryParse a XDocument

Creado en 15 jun. 2016 · 3Comentarios · Fuente: dotnet/runtime

Hola, este es un problemas de RFC a solicitar apoyo para una adición de un bool TryParse(string text, out XDocument document) método para el XDocument clase.

He buscado en el repositorio pero no puedo encontrar nada relacionado, así que si esto es un engaño, siéntete libre de cerrar.

Problema:

A veces sucede que tiene que trabajar con archivos XML que provienen de fuentes _no confiables_, y debe asegurarse de que el archivo sea realmente XML bien formado.

Actualmente, hay algunas formas no tan agradables de verificar que una cadena es un XML bien formado que implica el manejo de excepciones.

Ninguna de las formas sugeridas parece una solución limpia para un problema bastante común (al menos en mi opinión).

Tenga en cuenta también que otras clases BCL que exponen un método Parse(string source) generalmente también exponen un bool TryParse(string source, out...) lo que agregar un método TryParse hará que la clase XDocument algo más consistente con otras clases de BCL.

Sugerencia:

agregar el siguiente método

bool TryParse(string text, out XDocument document)

a XDocument y XElement clases

Pregunta:

¿Necesitamos paridad de funciones con las clases XmlDocument ?
En realidad, XmlDocument expone un LoadXml(string xml) por lo que podríamos agregar un bool TryLoadXml(string xml, out XmlDocument document) pero realmente no me gusta el nombre y, por lo tanto, si la paridad de características no es imprescindible, preferiría que no lo fuera. agregándolo

area-System.Xml

Fuente

ilmax

👍2

Comentario más útil

@weshaggard ,

Además de la conveniencia, un método TryParse permitiría a un desarrollador omitir los gastos generales asociados con los bloques try / catch y la creación de instancias de un XmlException no necesario que quizás ni siquiera le interese.

A mí también me sorprendió mucho descubrir que no existía tal método. :|

Crono1981 en 21 ago. 2019

👍2

Todos 3 comentarios

Revisamos esto y no entendemos completamente el valor de agregar un método TryParse en este caso. Si bien la coherencia con otros tipos de BCL es algo interesante, es mucho más útil en esos casos porque potencialmente está analizando muchos de ellos y, por lo tanto, hay un problema de rendimiento. En este caso, el rendimiento realmente no será un problema porque el costo de la excepción es pequeño en comparación con el costo de analizar todo el documento XML. Además, con los métodos Parse, obtendrá una XmlException sobre errores que brinda información adicional que lo señala al error de análisis que no tendría en los casos TryParse.

Para casos similares, las API de Roslyn no ofrecen un método TryParse para analizar un archivo CS porque generalmente desea más contexto sobre cualquier error, pero incluso eso puede ser excesivo para analizar documentos XML, por lo que tenemos el término medio de información básica en el Excepción Xml.

Gracias por el problema y por escribirlo, pero por estas razones no creemos que tenga mucho valor agregar un método TryParse a estos.

weshaggard en 11 oct. 2016

😕3

@weshaggard ,

A mí también me sorprendió mucho descubrir que no existía tal método. :|

Crono1981 en 21 ago. 2019

👍2

Para mí, personalmente, la respuesta de @weshaggard no tiene sentido. En mi opinión, todas las personas que usan .NET durante más de medio año están totalmente al tanto de las explicaciones en la primera parte de la publicación de @weshaggard. No manejar y no preocuparme por los errores en detalle es, al menos para mí en los últimos 20 años, la razón PRINCIPAL para usar una variante TryParse(), si la clase proporciona una.

Creo que mucha gente ya vino aquí en los últimos X años, después de mirar la publicación de stackoverflow al respecto, y dicen "oh. Realmente no hay TryParse() en XDocument. extraño".

Pero lo que sea.