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但却什么也不做），你必须明确这样做。

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

以某种方式处理异常。这可能意味着：

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为空，该怎么办？如果myIdx超出nodes数组的范围，该怎么办？这些条件中的任何一个都是例外，您应该专门处理它们或让调用程序处理它们并采取适当的行动。

[没有]我无法做（或需要做）修复行为

您可能无法修复它，但您可能需要了解它。在这种情况下，程序的行为有何不同？记录消息？提出警告？设置默认值？什么都不是一个合适的答案，但很可能不对任何可能的例外作出适当的回应。

Answer 3

为什么不检查该项目是否不是null？

if(nodes[myIdx].Attributes != null &&
   nodes[myIdx].Attributes["ows_FirstName"] != null) {
    /* ... your code ... */
}

或者：

if(nodes[myIdx].Attributes != null) {
   if(nodes[myIdx].Attributes["ows_FirstName"] != null) {
       /* ... your code ... */
   }
   if(nodes[myIdx].Attributes["ows_LastName"] != null) {
       /* ... your code ... */
   }
}

Answer 4

原因可能是因为如果您无法处理异常，不应该捕获异常。允许您try没有相应的catch只会做出最糟糕的做法。

至于您引用的特定代码，在尝试访问索引器之前，您是否只是进行空检查？

Answer 5

必须有另一种方法来检查属性是否存在，你不应该为某些功能目的使用异常处理，你这样编码：

try
{
    newstring = oldString.ToString();
}
catch{}

你应该做的是：

if(oldString != null)
{
    newstring = oldString;
}

请记住，try catch用于处理名为“exception”的内容

Answer 6

try / catch块是为了捕获和处理应用程序中抛出的异常而设计的。

简单地吞下异常通常是一个坏主意（即使您只是记录异常）并且必须明确地完成。

Answer 7

这是语言语法的一部分。如果没有至少一个try或catch，则无法finally。没有独立的try，只有try-catch，try-finally和try-catch-finally。

如果您不打算处理异常（try），或者至少确保某些后续代码始终运行而不管发生了什么，那么对catch某些代码没有意义（那是finally）。

Answer 8

在这个问题中已经回答了这个问题：C#: should all exceptions be caught

基本上，如果你正在捕捉它，那么你应该用它做点什么，否则不要抓住它。在您的情况下，为什么不能首先检查属性值是否存在？

Answer 9

看起来您正在使用其中一个SharePoint Web服务，因此返回类型是某种XmlElement？我非常确定有一种方法可以检查属性是否存在，这比抛出异常便宜。

另外，你想要一个封装检查和数据检索的辅助方法。

Answer 10

你不应该有空的catch块。这是糟糕的编程习惯。

让我想起了经典ASP On Error Resume Next

为什么try块需要捕获

10 个答案: