为什么 try 块需要一个 catch答案

【问题标题】：Why do try blocks need a catch为什么 try 块需要一个 catch
【发布时间】：2012-03-15 02:18:51
【问题描述】：

我有这个代码：

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

我知道异常处理的重要性，但这里的异常并没有什么特别之处，而且我无法（也不需要）修复该行为。

【问题讨论】：

阅读此[帖子][1] [1]：stackoverflow.com/questions/1573130/…
@CheGueVerra - 不确定这与我的问题有什么关系？

标签： c# syntax try-catch catch-block

【解决方案1】：

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

这个异常并没有什么特别的地方

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

例如——

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

[there's] 我无能为力（或需要做）来修复这种行为

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

【讨论】：

现在这是我看到的第一个合理的答案。我没有考虑如果它是我正在吞咽的另一种类型的异常会发生什么情况（尽管在我的示例中并不真正相关，但肯定会采取这一点）谢谢您的意见。

【解决方案2】：

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

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

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

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

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

【讨论】：

【解决方案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 ... */
   }
}

【讨论】：

因为 sharepoint XML webservices 具有简单地省略空属性而不是提供空值的奇妙行为。
很遗憾，属性集合通常至少包含一个值，因为您必须记住，通常您至少会返回几列。如果您只返回一列，这可能会起作用。希望这是有道理的。
这行得通，因为您总是可以检查多个列...我不太明白您的困惑在哪里...
我在回去检查你实际上是正确的之后很糟糕。您的解决方案确实有效。我很抱歉。

【解决方案4】：

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

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

你应该做的是：

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

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

【讨论】：

Sharepoint XML web 服务只是省略了空属性而不是提供空值。这意味着对于每个数据子集（即：每一行），我都需要遍历数据并进行检查。在我看来，简单地允许异常发生（尽管有争议）更为实际。

【解决方案5】：

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

至于你引用的具体代码，你不能在尝试访问索引器之前做一个空检查吗？

【讨论】：

请看我对 Simon Wang 和 Xander 的回复我的具体代码

【解决方案6】：

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

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

【讨论】：

【解决方案7】：

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

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

【讨论】：

【解决方案8】：

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

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

【讨论】：

我不相信有办法检查 XmlAttributeCollection （我看过但可能是错的）但即使有我仍然会争辩说在某些情况下这种语法是合适的.

【解决方案9】：

这是语言语法的一部分。您不能在没有至少一个 catch 或 finally 的情况下使用 try。没有独立的try，只有try-catch、try-finally和try-catch-finally。

如果您不想费心处理异常 (catch)，或者至少要确保无论发生什么情况，一些后续代码始终运行 (@987654333)，那么 try 一些代码根本没有意义@)。

【讨论】：

大概他在问为什么这是语法。

【解决方案10】：

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

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

【讨论】：