|
|
1
8
我想你要问的是:
外部try/catch块用于在试图打开或读取文件时处理是否正确关闭读卡器对象。内部try/catch块将吞入读取数据格式错误且无法正确分析时引发的异常。 不过,我几乎同意其他人的看法。吞下这个例外可能不太好。至少,我建议你把它记录在某个地方。 |
|
|
2
5
简而言之,您可能不应该为此使用异常。像TryParse这样返回false的东西更有效,也更容易恢复。异常处理有点生硬。 |
|
|
3
3
一般来说,像这样:
你应该避免抓到将军
|
|
|
4
2
这里有一些很好的背景信息: Is there any valid reason to ever ignore a caught exception 简而言之:以这种方式使用异常非常昂贵。如果可能的话,在发送输入进行处理之前测试它,并忽略它而不是忽略异常。 还要确保你没有撒太大的网,吃合法的例外,你可能想知道。 |
|
|
5
1
如果希望常规异常只抛出一个或两个特定异常类型来分析特定错误,那么捕获常规异常是一个坏主意。通常最好捕获每个特定的异常类型并独立处理它,这样代码就不会抑制任何其他(可能是意外的)错误(例如,如果文件丢失或网络连接超时,是否应该以与文件包含损坏数据相同的方式处理它?) 但是,如果您有意需要/想要捕获所有可能的错误并优雅地继续,那么捕获一般异常是一个好主意。如果对所有错误类型的处理都相同(例如,“如果出于任何原因,我无法读取此首选项值,我将返回默认值5”-这比程序崩溃要好得多,因为您没有意识到它可能由于网络超时而引发异常)。如果使用得当,这种方法可以使你的程序防弹,但如果使用不当,你可以抑制错误,你需要知道和修复,这可能是非常痛苦的。 在抑制任何异常时,您应该始终仔细考虑错误报告-是否应该告诉用户您遇到了问题?您是否应该将其记录在跟踪文件中,以便当客户抱怨某些东西不正常时,您可以追溯到问题的根源?或者你应该默默地忽略它?只是要小心,因为过度热情的压制会让人很难弄清楚为什么一个程序的行为是不可预测的。 |
|
|
6
0
这是可行的——也许你也可以记录错误,如果你想知道是什么数据导致了异常的发生,并用它来改进你的解析逻辑。 |
|
|
7
0
我有种感觉,你看到的东西像黑白的,这感觉不对。。是的,大多数情况下,捕获所有内容并不是一件好事,在输入的验证方面也不尽如人意,但并非总是如此。这很可能是个特例。我不知道要解析什么类型的文件,但异常可能是正确的。 在我们决定什么是最好的之前,给我们更多的细节:) |
|
|
8
0
|