我知道..我知道...性能不是这里主要关心的问题,只是出于好奇,什么更好?
bool parsed = int.TryParse(string, out num);
if (parsed)
...
或
try {
int.Parse(string);
}
catch () {
do something...
}
更好是非常主观的。例如,我个人更喜欢
int.TryParse
,因为我通常不关心 为什么 解析失败(如果失败)。然而,int.Parse
可以(根据文档)抛出三个不同的异常:
如果您关心它失败的原因,那么
int.Parse
显然是更好的选择。
一如既往,上下文为王。
转换有时会失败是异常,还是转换有时会失败是预期且正常?如果是前者,请使用例外。如果是后者,避免例外。异常被称为“异常”是有原因的;您应该只使用它们来处理特殊情况。
如果确实预计转换有时会失败,我喜欢使用
int.TryParse
并与 条件(三元)运算符整齐地放在一行,如下所示:
int myInt = int.TryParse(myString, out myInt) ? myInt : 0;
在这种情况下,如果 TryParse 方法失败,将使用零作为默认值。
对于可空类型也非常有用,如果转换失败,它将用
null
覆盖任何默认值。
第一个。第二个被认为是异常编码。
就我个人而言,我更喜欢:
if (int.TryParse(string, out num))
{
...
}
第一个!你不应该通过异常来编码。
你可以将其缩短为
if (int.TryParse(string, out num))
首先,到目前为止。正如乔治所说,第二个是异常编码,它对性能有重大影响。性能应该始终成为一个问题。
捕获异常需要更多开销,所以我会选择 TryParse。
if (int.TryParse(string, out num))
另外,如果转换失败,TryParse 方法 不会引发异常。如果转换无效且无法成功解析,则无需使用异常处理来测试 FormatException。
还需要记住的是,异常会记录在 Visual Studio 调试/输出窗口中(可选)。即使异常的性能开销可能微不足道,在调试时为每个异常编写一行文本也会减慢速度。更值得注意的异常也可能被淹没在失败的整数解析操作的所有噪音中。