C#尝试捕获模式帮助

Question

我们总是需要尝试捕获我们的代码,它变得丑陋像

public void foo()
{
  try
  {
    DoSomething();
  }
  catch(Exception e)
  {
     //do whatever with e
  }
}

public int FooReturnInt()
{
  try
  {
     return IntAfterSomeCalculation();
  }
  catch(Exception e)
  {
    //do exactly whatever with e as foo()
  }
}

想象一下,我们有一个庞大的类,有许多像这样的公共函数,我们必须在每个函数中应用相同的try catch.

理想情况下,因为try catch部分是相同的,我们可以将Func <>作为参数传递给辅助函数,它执行类似的操作

public void TryCatch(Func<something> theFunction)
{
  try
  {
    theFunction();
  }
  catch(Exception e)
  {
    //processthe common exception        
  }
}

然后我想象这会整理我的代码很多,现在的问题是如何正确编写这个函数？此函数的返回类型取决于函数的返回类型.

Answer 1

如果你真的认为这是必要的,你可以使用:

public T TryCatch<T>(Func<T> theFunction)
{
  try
  {
    return theFunction();
  }
  catch(Exception e)
  {
    // You'll need to either rethrow here, or return default(T) etc
  }
}

但是,我通常会反对它.您确定在所有这些方法中都需要try/catch块吗？通常不应该有很多try/catch块,除非catch只包装异常并重新抛出...例如,在C#中甚至比在Java中更少见.

当你可以正常地正确处理它或者你需要阻止进程因为一个请求失败而爆炸时(例如),你通常应该捕获异常.我倾向于写很少的catch块 - 我真的可以从错误中恢复,这是相对罕见的:)

我怀疑,这种方法会导致调试时间变得非常困难.它可能仍然值得做,但你应该首先仔细考虑利弊.

Answer 2

使用catch块有三个原因:

1因为可能有例外.

这是错误的原因.

2因为你可以以某种方式处理异常.

这是正确的理由.

3因为您要添加和/或隐藏详细信息

这个捕获和包裹,涉及重新投掷,并不是真正的捕获.

这里的主要思想是不熟悉异常处理的程序员倾向于使用(方式)过多的catch块.你似乎属于这一类.

Answer 3

虽然您可以使用帮助器/包装器方法,但您不应该以这种方式构造代码.看起来你正在尝试像返回成功/错误代码的旧系统一样使用try/catch.您的公共函数实际上应该抛出相应类型的异常,并且API的使用者应该在某种程度上使用try/catch来管理异常条件.

try/catch异常机制旨在通过允许异常"渗透"调用堆栈直到找到处理程序,使开发人员不必从代码深处链接返回代码.(唯一一次看到异常的时候是一系列调用中的任何方法未对其进行处理.)无论如何,这是一个很好的开始这个主题的地方.

这里有一个"经验法则"博客文章,比MSDN文章更容易理解.而另一个链接有更加简称内容.

摘自上一个链接:

1. 不要抓住你无法处理的例外情况
2. 永远不要吞下例外
3. 您的代码应该具有比Try/Catch更多的Try/Finally(或使用)
4. 永远不要抛出/捕获新的Exception()(太宽泛的类)而是尝试thow\catch一个更加派生的异常(ArgumentNullException等)
5. 当重新抛出异常时使用throw; 抛出ex; 这样可以防止堆栈跟踪被重置
6. 在编写库与应用程序时,我永远不会期望,除非我能确定地处理它
7. 使用逻辑来控制程序的流程而不是异常,检查NULL而不是捕获ArgumentNullException

6号直接适用于您的情况.