当数据理论上总是正确时使用 TryParse 或 Parse 进行解析？答案

【问题标题】：Parsing with TryParse or Parse when data is theoretically always correct?当数据理论上总是正确时使用 TryParse 或 Parse 进行解析？
【发布时间】：2011-11-30 08:25:54
【问题描述】：

我查看了其他一些问题（尤其是Parsing Performance (If, TryParse, Try-Catch)），并且正在考虑答案。如果不应该抛出异常，是否滥用异常处理？这不是重点吗？在出现问题的罕见情况下捕获错误？

确切地说，我从一项服务中获取了一些 xml 数据，我想知道我是否可以假设它是正确的（其中 .00000001% 有点/其他东西在互联网上丢失了）。

编辑我可能会使用 Linq to XML，但问题仍然存在。

【问题讨论】：

异常处理的“问题”是它总是会产生一些开销，即使没有抛出异常。我会接受您提到的问题的公认答案。
@Marcel 不抛出时的开销非常小，但异常肯定不是进行流量控制的好方法

标签： .net parsing try-catch

【解决方案1】：

我更看重场景而不是表演；如果 预期行为 是有效的，我通常使用 Parse（或 ParseExact，如果可用），并让异常消失。除非我需要提出一个特定的错误，在这种情况下 TryParse 很方便。

如果数据可能是（比如说）一个整数，那么 TryParse 比 Parse+catch 更可取。

使用 LINQ-to-XML：不要解析；相反，使用提供的静态转换运算符；所以而不是：

...
select int.Parse(node.Value);

你应该使用

...
select(int) node;

这对于 DateTime 之类的内容更为重要，因为它考虑了标准 XML 格式。如果节点不存在（即node 是null），它也会执行“预期”的操作：

select (int?)node;

将返回一个null 值，而不是抛出一个NullReferenceException（node.Value 会这样做）。大多数预期的数据类型都有静态转换运算符。

【讨论】：

您是说演员阵容，而不是“case”吗？
DateTime 是使用演员表的一个有趣的选择。这是我自己进行解析和转换以确保不会发生任何奇怪事情的地方之一。
@CodeInChaos 这取决于预期的格式，我猜；如果它是标准的 xml 日期/日期时间/等，那么转换运算符将干净地完成这项工作

【解决方案2】：

我假设该服务通常会返回有效数据，但我仍会尝试防止外部组件出现故障。如果该服务在您自己的控制之下，并且您非常确定它永远不会返回无效数据，您可以简单地使用Parse 并完成。但是，如果它不在您的控制之下，那么优雅地处理故障是很好的。

我会在处理解析的代码的最外层放置一个catch 子句。并将任何解析错误转换为通用的“来自服务的无效数据”异常，原始异常为内部异常。

然后调用代码可以处理那个异常，因此它不会关闭您的整个应用程序。

【讨论】：