Runtime: Adicionar TryParse ao XDocument

Criado em 15 jun. 2016 · 3Comentários · Fonte: dotnet/runtime

Oi, este é um RFC questões de suporte pedido de adição de um bool TryParse(string text, out XDocument document) método para o XDocument classe.

Pesquisei no repositório, mas não encontrei nada relacionado, portanto, se for um engano, sinta-se à vontade para fechar.

Problema:

Às vezes acontece que você tem que trabalhar com arquivos XML que vêm de fontes _não confiáveis_, e você tem que garantir que o arquivo seja realmente XML bem formado.

Atualmente, existem algumas maneiras não tão boas de verificar se uma string é um XML bem formado que envolve o tratamento de exceções.

Nenhuma das maneiras sugeridas parece uma solução limpa para um problema bastante comum (pelo menos IMO).

Observe também que outras classes BCL que expõem um método Parse(string source) geralmente também expõem um método bool TryParse(string source, out...) portanto, adicionar um método TryParse tornará a classe XDocument um pouco mais consistente com outras classes BCL.

Sugestão:

adicione o seguinte método

bool TryParse(string text, out XDocument document)

para aulas de XDocument e XElement

Pergunta:

Precisamos de paridade de recursos com classes XmlDocument ?
Na verdade, XmlDocument expõe um LoadXml(string xml) para que possamos adicionar um bool TryLoadXml(string xml, out XmlDocument document) mas eu realmente não gosto do nome e, portanto, se a paridade de recursos não for obrigatória, prefiro não adicionando-o.

area-System.Xml

Fonte

ilmax

👍2

Comentários muito úteis

@weshaggard ,

Além da conveniência, um método TryParse permitiria que um dev pule a sobrecarga associada aos blocos try/catch e a instanciação de um XmlException não necessário com o qual ele pode nem se importar.

Eu também fiquei muito surpreso ao descobrir que tal método não existia. :|

Crono1981 em 21 ago. 2019

👍2

Todos 3 comentários

Revisamos isso e não entendemos completamente o valor de adicionar um método TryParse neste caso. Embora a consistência com outros tipos de BCL seja um pouco interessante, é muito mais útil nesses casos porque você está analisando potencialmente muitos deles e, portanto, há um problema de desempenho. Nesse caso, o desempenho não será realmente um problema porque o custo da exceção é pequeno comparado ao custo de analisar todo o documento XML. Além disso, com os métodos Parse, você obterá uma XmlException nos erros, que fornece informações adicionais que apontam para o erro de análise que você não teria nos casos TryParse.

Para casos semelhantes, as APIs do Roslyn não oferecem um método TryParse analisando um arquivo CS porque geralmente você deseja mais contexto em qualquer erro, mas mesmo isso pode ser um exagero para analisar documentos XML e é por isso que temos o meio termo de informações básicas no XmlException.

Obrigado pelo problema e por escrevê-lo, mas por esses motivos, não achamos que haja muito valor em adicionar um método TryParse a eles.

weshaggard em 11 out. 2016

😕3

@weshaggard ,

Eu também fiquei muito surpreso ao descobrir que tal método não existia. :|

Crono1981 em 21 ago. 2019

👍2

Para mim, pessoalmente, a resposta de @weshaggard faz 0 sentido. Imo todas as pessoas por aí, usando .NET por mais de meio ano, estão totalmente cientes das explicações na primeira parte do post de @weshaggard. Não lidar e não se importar com erros em detalhes é, pelo menos para mim nos últimos 20 anos, o motivo PRINCIPAL, usar uma variante TryParse(), se a classe fornecer uma.

Eu acho que um monte de ppl já veio aqui nos últimos X anos, depois de olhar o post do stackoverflow sobre isso, e dizer "oh. realmente não há TryParse() no XDocument. estranho."

Mas de qualquer forma.