TryCatch 与 TryParse 的优缺点
使用以下任一方法从对象中提取双精度值有何优缺点?除了个人喜好之外,我寻求反馈的问题还包括调试的难易性、性能、可维护性等。
public static double GetDouble(object input, double defaultVal)
{
try
{
return Convert.ToDouble(input);
}
catch
{
return defaultVal;
}
}
public static double GetDouble(object input, double defaultVal)
{
double returnVal;
if (double.TryParse(input.ToString(), out returnVal))
{
return returnVal;
}
else
{
return defaultVal;
}
}
What are the pros and cons of using either of the following approaches to pulling out a double from an object? Beyond just personal preferences, issues I'm looking for feedback on include ease of debugging, performance, maintainability etc.
public static double GetDouble(object input, double defaultVal)
{
try
{
return Convert.ToDouble(input);
}
catch
{
return defaultVal;
}
}
public static double GetDouble(object input, double defaultVal)
{
double returnVal;
if (double.TryParse(input.ToString(), out returnVal))
{
return returnVal;
}
else
{
return defaultVal;
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在某些情况下,最好使用
try catch
块主动查找或检查输入。例如,如果我们有一个带有用于 ineteger 到字符串转换的查找表的字典,那么如果我们只使用
ContainsKey
而不是使用try catch
来检查键,那么性能会很好In some cases it is better to proactively look or check for the input against using
try catch
block.Example if we have a dictionary with lookup table for ineteger to string conversion it is good performance wise if we just use
ContainsKey
instead of usingtry catch
for checking the keyTryParse 更快,通常更好,但我建议在框架和后端编程中使用 TryCatch 方法,因为您可以向客户端提供有关错误的更多信息:
TryParse is faster and usually better but I would suggest the TryCatch approach in framework and back-end programming because you can give more information to the client about the error:
让 Parse 方法在错误输入时抛出异常是一个设计缺陷。当您从用户处获取数据时,错误输入是预期的行为。抛出异常的成本很高,您不希望在代码中经常发生这种情况。
值得庆幸的是,微软意识到了他们的错误并添加了 TryParse 方法。 TryParse 确实不会产生错误输入引发异常的开销,但缺点是它必须返回两条数据,所以使用起来感觉有点尴尬。
现在,如果他们没有首先创建损坏的 Parse 实现,TryParse 就会被称为 Parse。
Having the Parse methods throw exceptions on bad input was a design flaw. Bad input is expected behavior when you take in data from a user. Exception throwing is expensive, it's not something you want happening routinely in your code.
Thankfully, Microsoft realized their mistake and added the TryParse methods. TryParse does not incur the overhead of exception throwing on bad input, but the downside is it has to return two pieces of data, so it feels a bit awkward to use.
Now if they hadn't created the broken Parse implemetation in the first place, TryParse would just be called Parse.
TryParse 比 TryCatch 性能更高效。
TryParse is more efficient than TryCatch performance wise.
TryParse
比捕获异常更快TryParse
指示了一些预期 - 这里没有发生任何异常,只是您怀疑您的数据可能不是有效的。TryParse
不使用正常控制流的异常处理基本上,使用
TryParse
:)顺便说一句,您的代码可以重写为:
TryParse
will be faster than catching an exceptionTryParse
indicates something expected - nothing exceptional is happening here, it's just that you suspect your data may not be valid.TryParse
isn't using exception handling for normal control flowBasically, go with
TryParse
:)By the way, your code can be rewritten as: