try catch的用法

时间:2011-06-21 14:08:33

标签: c# try-catch

哪个最好:代码段1或代码段2?为什么?

/* Code Snippet 1
 * 
 * Write try-catch in function definition
 */
 void Main(string[] args)
 {
     AddMe();
 }

 void AddMe()
 {
     try
     { 
         // Do operations...
     }
     catch(Exception e)
     {
     }
 }

/* Code Snippet 2
 * 
 * Write try-catch where we call the function.
 */
 void Main(string[] args)
 {
     try
     {
         AddMe();
     }
     catch (Exception e)
     {
     }
 }

 void AddMe()
 {
     // Do operations...
 }

7 个答案:

答案 0 :(得分:4)

要问的真正问题是“AddMe与世界其他地方的合同是什么?”如果AddMe表示一个接口的全部操作并正确处理以适当方式遇到的任何异常,那么确定 - 让它捕获它。如果AddMe不知道或不知道如何处理异常,那么它应该抛出并将处理推迟到调用代码。

答案 1 :(得分:2)

这与往常一样。

在Snippet#1中,错误处理是可重用的。在Snippet#2中,它不是,但如果您想在不同的地方使用不同的错误处理,情况会更好。

除此之外,它们完全相同。

答案 2 :(得分:1)

它们将运行相同但是大多数人更愿意捕获方法中的逻辑,如果它将被抛出的那样。只是一个最好的做法。

答案 3 :(得分:1)

没有最好的通用方式。这取决于你将如何处理你的异常。

您是否计划在主应用程序中使用全局记录器?你应该在main方法中有一个try / catch块,并在那里记录异常。

如果您需要使用异常执行其他操作,您仍然可以尝试/ catch内部方法,但请记住重新抛出它们,否则主方法中的记录器将无法记录任何内容。

请记住,要正确地重新抛出,请使用:

throw;

而不是:

throw e;

因为前者保留所有堆栈跟踪,而后者不跟踪。

答案 4 :(得分:1)

恕我直言,允许方法抛出异常。当出现问题时,不要试图隐藏。当他们这样做时,由客户决定他们如何处理异常。这样做的原因是因为每个应用程序可能希望对异常执行不同的操作。

答案 5 :(得分:1)

TL,DR;当您可以对异常执行某些操作时捕获异常,否则让它们向上流动调用堆栈,直到其他东西将处理它们。如果应用程序的任何特定部分无法处理异常,则应用程序错误事件方法应该为您处理所有日志记录。您的日志记录功能将成为处理异常的最终网络。

我和一些需要在每个方法上尝试捕获逻辑的商店一起工作,并且我了解到Exception对象在监视调用堆栈方面做得比你能做得更好。

我的另一个经验法则是通知用户有关用户触发事件的异常。因此,基于事件或基于命令的捕获将是捕获,通知然后重新抛出相同异常的好地方。 (IE抛出;不要扔ex;)

答案 6 :(得分:0)

这个问题已经有了很好的答案,最终归结为“它取决于”,但我想补充一个我认为会对任何特定情况下哪种方法更好的影响的想法。

在您的代码段示例中,但您的捕获量为catch (Exception e) {},而不是catch (IOException e)catch (NullReferenceException,或其他一些较窄的异常类型。您期望从try块中的代码中获得的异常类型将对您希望处理它的方式产生影响。特别是如果您要考虑多种类型,如果您处理子例程之外的异常就可能出现这种情况 - 一个足够大的上层try块可能有几种不同类型的异常要处理,并开始冒着使代码混乱的风险。

总的来说,我的一般经验法则是,如果异常是非严重错误(特别是由无效的用户输入引起),我可以在子程序中处理它并保持系统运行。另一方面,如果异常意味着程序需要关闭,我会把它处理得更高。

相关问题