为什么try块需要捕获

Question

我有一些代码

try
{
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value;
} catch { }

如果我正在寻找的属性存在(Good ol sharepoint),我现在不知道在调用此调用之前.

因此,我可以编写我想要创建的代码的唯一线性方式就是这样.

try
{
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value;
} catch { }
try
{
    result.LastName = nodes[myIdx].Attributes["ows_LastName"].Value;
} catch { }

....

现在我没有使用此代码的catch部分,最终得到了大量完全冗余的行.

为什么我不能这样做

try { result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value; }

那么为什么我们明确被迫声明一个catch块,即使它没有被处理？我确信有充分的理由,但无法解决.

编辑:在每个人开始对我说,吞下一个例外是不好的,等等等等等等.我们(和我)都知道这些论点,但在这个(和许多)现实世界场景中,没有什么特别的例外,我无法做(或需要做)来修复行为.

Answer 1

如果你想吞下一个异常(catch它什么也不做),你必须明确地这样做.

这通常是不好的做法,因此没有理由提供语法快捷方式.你通常应该:

1. 以某种方式处理异常.这可能意味着:

a. Retry
b. Rethrow it (preserving the inner exception) with a more meaningful message.
c. Do it another way.
d. Log it (though logging and rethrowing might be better).
e. Other

2.让它冒泡(不试试,或者只是尝试/最后).

Answer 2

它们并不多余 - 它们有特定的目的.默认情况下,缺少catch块会将异常重新抛出到调用方法.一个空catch块基本上"吞下"异常并让程序继续,不知道是否抛出异常; 通常是一种不好的做法

这个例外没有什么特别之处

它可能是真实的,一种类型的异常可能不会在这种情况下,"例外",但是这不是唯一可能出现异常.您应该处理该异常并适当地处理任何其他人.

例如 -

如果nodes是null怎么办？如果myIdx超出nodes数组的范围怎么办？这些条件中的任何一个都是例外的,您应该专门处理它们或让调用程序处理它们并采取适当的行动.

[没有]我无法做(或需要做)修复行为

您可能无法修复它,但您可能需要了解它.在这种情况下,程序的表现如何？记录消息？提出警告？设置默认值？什么都不是适当的答案,但很可能不是对任何可能的例外的适当回应.