5

我有一些这样的代码

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 块，即使它没有被处理呢？我确信有一个很好的理由，但无法解决。

编辑：在每个人开始对我发火之前，吞下一个例外是不好的，等等等等。我们（和我）都知道这些论点，但在这个（以及许多）现实世界的场景中，这个异常并没有什么特别之处，我也无能为力（或需要做）来修复这种行为。

4

10 回答 10

6

如果你想吞下一个异常（catch它但什么都不做），你必须明确地这样做。

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

  1. 以某种方式处理异常。这可能意味着：
一个。重试
湾。用更有意义的消息重新抛出它（保留内部异常）。
C。换一种方式。
d。记录它（尽管记录和重新抛出可能会更好）。
e. 其他

2.让它冒泡（不要尝试，或者只是尝试/最终）。

于 2012-03-15T02:21:08.433 回答
6

它们不是多余的——它们有特定的目的。默认情况下，缺少catch块将重新向调用方法抛出异常。一个空catch块本质上“吞下”了异常并让程序继续运行，而忽略了是否抛出了异常；通常是一种不好的做法。

例外没有什么例外

在这种情况下，一种类型的异常可能不是“异常”，但这可能不是唯一可能发生的异常。您应该处理该异常并适当地处理任何其他异常。

例如 -

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

[没有]我能做（或需要做）任何事情来解决这个问题

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

于 2012-03-15T02:25:10.743 回答
4

为什么不检查该项目是否不是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 ... */
   }
}
于 2012-03-15T02:22:58.123 回答
3

必须有另一种方法来检查该属性是否存在，您不应该将异常处理用于某些功能目的，您的代码如下：

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

你应该做的是：

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

请记住，try catch 用于处理名为“异常”的事物

于 2012-03-15T02:24:09.477 回答
2

原因可能是因为如果您无法处理异常，则不应捕获它。允许您在try没有相应的情况下catch这样做只会导致最糟糕的做法。

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

于 2012-03-15T02:22:17.577 回答
1

try/catch 块被明确设计用于捕获和处理应用程序中抛出的异常。

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

于 2012-03-15T02:21:35.657 回答
1

它是语言语法的一部分。你不能try没有至少一个catch，或一个finally。没有独立try的，只有try-catch,try-finally和try-catch-finally。

try如果您不想费心处理异常（catch），或者至少确保某些后续代码始终运行，无论发生什么（即），它对某些代码根本没有意义finally。

于 2012-03-15T02:22:55.750 回答
1

这个问题几乎已经回答了这个问题：C#: should all exceptions be catched

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

于 2012-03-15T02:23:34.967 回答
1

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

此外，您还需要一个封装检查和数据检索的辅助方法。

于 2012-03-15T02:25:36.983 回答
0

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

让我想起了经典的 ASPOn Error Resume Next

于 2012-03-15T02:24:40.680 回答