方法定义或调用中的异常处理？

我想知道是否有合适的地方来处理异常。我应该在我的方法中处理它，还是应该在方法调用中处理它？或者它有什么关系？方法定义或调用中的异常处理？

对不起，但我找不到任何关于此（谷歌搜索“异常处理范围”没有返回我正在寻找）。

实施例：

// this way... 
void readFile(string file) 
{ 
    try 
    { 
     /* do my stuff */ 
    } 
    catch(Exception exception) 
    { 
     /* handle exception */ 
    } 
} 

int main() 
{ 
    readFile(file); 
} 

// or this way? 
void readFile(string file) 
{ 
    /* do my stuff */ 
} 

int main() 
{ 
    try 
    { 
     readFile(file); 
    } 
    catch(Exception exception) 
    { 
     /* handle exception */ 
    } 
}

预先感谢。

来源

2011-11-16 efermat

人们请停止回答这个大量的重复。 –

我很抱歉，但正如我所说，我找不到任何回答我的问题的东西。我很感激，如果你可以张贴链接重复，甚至告诉我一些'搜索条件'。 – efermat

@John：如果是重复的，请投票结束。 –

一般而言，您希望处理这样做的错误。

如果在上面的示例中，您想尝试读取文件，如果该文件失败，请阅读默认文件，您可以像第一个示例中那样处理它。

如果readFile操作失败对main（）的其余部分至关重要，那么您需要将异常传递给它，以便它可以处理readFile（）失败的任何后果，并且这将在第二次例。

当然，您可以随时处理方法中的错误（或一些可能的例外），并重新抛出或让某些通过或其他方式。

真的，虽然它的程序流程决定了你的异常处理的位置。在有意义的情况下处理异常。

来源

2011-11-16 18:15:26 Chris

最好的做法是让上层处理异常。想象一下，你正在将你的底层文件阅读器打包到一个库中，并在那里处理异常。您不会让您的代码的用户有能力以他们所期望的方式处理异常。

来源

2011-11-16 18:13:34 Tudor

我知道Eric Lippert喜欢让例外情况像现在一样飙升到顶级水平，但我不同意。假设IDictionary.Add的实现调用了一个引发InvalidOperationException的方法。调用者可能期望捕获InvalidOperationException，并认为这样的异常将意味着字典已经保存了密钥，但是在其他情况下处于合法状态。捕捉，包装和重新抛出异常似乎是避免该问题的最佳方法。太糟糕了，现有的异常机制并不会特别方便。 – supercat

如果你可以处理异常，从它恢复并继续，那么你应该立即做到这一点。

另一方面，如果没有什么明智的做法可以处理异常，那么最好的办法就是让异常在调用堆栈中传播。最终，顶层代码将被迫捕获异常并将其记录/显示给用户，否则应用程序将崩溃。

来源

2011-11-16 18:15:54

只有在您确实计划在特定情况下做某件事情时才处理异常（例如，与DB交谈并发生死锁异常，您可能希望重试DB操作）。如果您只是想做一些通用的异常处理操作（例如记录每个异常），请尽可能在最高级别（通常是UI）中执行此操作，并且不要将代码与各处的异常处理程序混淆在一起 - 只要让异常出现泡沫即可。

来源

2011-11-16 18:16:09

第一种方法通常比较好，因为所有的文件都由readFile处理，调用readFile的代码不必担心文件处理问题。然而，你可以从readFile返回一个布尔值，告诉调用者操作是否成功：

bool readFile(string file) 
{ 
    try { 
     /* do my stuff */ 
     return true; 
    } catch(Exception exception) { 
     /* handle exception */ 
     return false; 
    } 
}

来源

2011-11-16 18:17:22

如果readFile的调用者想要对异常执行其他操作而不是您正在执行的操作，该怎么办？上面的代码将无法访问异常详细信息。 – Tudor

如何将异常作为“ref”或“out”参数传递？请注意，如果有人希望调用者在不必使用Pokemon异常异常处理的情况下进行恢复，那么让异常冒泡调用堆栈不是合理的选择。必须要么包装并重新抛出异常，要么必须通过其他方式让调用者知道操作失败的方式不会破坏系统的其他部分。如果调用者将要预测异常，将它作为“ref”或“out”参数返回似乎比包装和重新抛出它更好。 – supercat

你是对的，不同的方法是可能的。它总是取决于你想要做什么。尽管如此，如果发现更容易处理不会抛出异常并限制问题而不是传播它们的方法。 –

方法定义或调用中的异常处理？

回答

相关问题