更好的是： int.TryParse 或 try { int.Parse() } catch [关闭]答案

【问题标题】：What is better: int.TryParse or try { int.Parse() } catch [closed]更好的是： int.TryParse 或 try { int.Parse() } catch [关闭]
【发布时间】：2011-06-24 03:56:39
【问题描述】：

我知道..我知道...性能不是这里的主要关注点，只是出于好奇，什么更好？

bool parsed = int.TryParse(string, out num);
if (parsed)
...

或

try {
    int.Parse(string);
}
catch () {
    do something...
}

【问题讨论】：

标签： c# .net parsing type-conversion tryparse

【解决方案1】：

更好是非常主观的。例如，我个人更喜欢int.TryParse，因为我通常不关心为什么解析失败，如果它失败了。但是，int.Parse 可以（根据documentation）抛出三个不同的异常：

输入为空
输入的格式无效
输入包含一个会产生溢出的数字

如果您关心失败的原因，那么int.Parse 显然是更好的选择。

一如既往，语境为王。

【讨论】：

虽然我同意上下文为王的一般推论，但我想说 TryParse几乎总是更好，但它不仅仅是一个高度主观的个人偏好。您的反例（区分可以抛出的不同异常）是相当不寻常的，并且可能会更好地为每种异常类型编写一个 catch 块而不是全部捕获。
@Joe：是的，如果你想区分不同的异常类型，除了特定的 catch 块之外的任何东西都会显得很奇怪。我的回答旨在讨论Parse 与TryParse，而不是问题中的具体代码示例。正如我在 cmets 其他地方提到的那样，我同意 TryParse 是几乎总是更好的方法，但关键字是“几乎”，而不是“总是”。
@Joe：我已经提出了这个论点。请参阅对原始问题的评论交流。 Fredrik 关于绝对陈述永远不正确的权利。（天哪，一个悖论！）
向国王致敬，宝贝。

【解决方案2】：

转换有时会失败是异常，还是转换有时会失败预期且正常？如果是前者，请使用异常。如果是后者，避免异常。异常被称为“异常”是有原因的；您应该只使用它们来处理特殊情况。

【讨论】：

我喜欢这个解释，因为我解析了大量的用户数据，而失败是否在意料之中（以及当它发生时该怎么办）塑造了整个项目。
Eric，我很想听听你对 boost.org/community/error_handling.html 的看法：“is this an exceptional (or unexpected) situation?'' This guideline has an attractive ring to it, but is usually a mistake... A more appropriate question to ask is: 我们要在这里展开堆栈吗？''”
@Jon：我想到了几件事。首先，您不能与重言式争论，即在您想要异常行为的情况下异常是正确的，但您也无法从中学到任何东西。其次，“异常”和“意外”是两个不同的东西。第三，谁说堆栈展开与它有关？这是 C# 的实现细节。异步方法中抛出的异常不会展开堆栈；堆栈早已不复存在。它们向任务发出异常事件发生的信号。不要将语义与实现混淆。
我同意 boost 指导方针提出了一个问题，“我们应该什么时候想要堆栈展开？”，但这句话也是正确的：“问题是一个人的'例外'是另一个人的'预期的'”解析失败是否异常？到达文件末尾是否异常？我们如何客观地确定这一点？

【解决方案3】：

如果确实预计转换有时会失败，我喜欢使用int.TryParse 和conditional (Ternary) operator 这样整齐地放在一行中，像这样：

int myInt = int.TryParse(myString, out myInt) ? myInt : 0;

在这种情况下，如果 TryParse 方法失败，将使用零作为默认值。

对于可空类型也非常有用，如果转换失败，它将用null 覆盖任何默认值。

【讨论】：

这完全等同于：int myInt; int.TryParse(myString, out myInt);。 TryParse() 在失败时已经将结果设置为 0。
正确，但在我的版本中，您可以指定 alternative 默认值，例如 10。

【解决方案4】：

第一个。第二种被认为是异常编码。

【讨论】：

【解决方案5】：

就个人而言，我更喜欢：

if (int.TryParse(string, out num))
{
   ...
}

【讨论】：

【解决方案6】：

第一个！您不应该按异常编写代码。

你可以把它缩短为

if (int.TryParse(string, out num))

【讨论】：

【解决方案7】：

首先，到目前为止。正如乔治所说，第二个是异常编码，对性能有重大影响。性能应该始终是一个问题。

【讨论】：

【解决方案8】：

捕获异常需要更多开销，所以我会选择 TryParse。

另外，如果转换失败，TryParse 方法不会抛出异常。它消除了在 s 无效且无法成功解析的情况下使用异常处理来测试 FormatException 的需要。

最后一部分从here复制粘贴

【讨论】：

【解决方案9】：

另外需要记住的是，异常会（可选）记录在 Visual Studio 调试/输出窗口中。即使异常的性能开销可能微不足道，在调试时为每个异常编写一行文本也会减慢速度。更值得注意的异常也可能淹没在失败的整数解析操作的所有噪音中。

【讨论】：