最好检测异常并抛出它们或只是让运行时抛出它们?

时间:2012-04-02 12:55:13

标签: c# .net design-patterns tdd

让我们说有这样的设置:

public class MyClass
{
    public void DoSomething(string Data)
    {
      //if (String.IsNullOrWhiteSpace(Data))
        //throw new NullReferenceException();

      //Do something with Data and let it throw??
    }
}


public class EntryPointClass
{
  public void DoIt(string Data)
  {
     var logicClass = new MyClass();

     try
     {
        logicClass.DoSomething(Data);
     }
     catch(Exception ex)
     {

     }
  }
}

在DoSomething中,我可以检测到问题并抛出异常。在测试EntryPointClass时,我可以测试预期结果或测试catch中发生的事情。

为什么抛出异常而不是等待一个异常更好?无论哪种方式,我们都抓住了它!

6 个答案:

答案 0 :(得分:4)

你同时做到了:

public void DoSomething(string Data)
{
  if (String.IsNullOrWhiteSpace(Data))
    //throw new NullReferenceException();  
    throw new ArgumentException("Data");


  //Do something with Data and let it throw??
}

目标是尽早提供并提供具体信息 扔在这里的直接原因是与DoSomething()的合同被打破了。发信号,不要等待`DoSomething()进行并打破其他合同。

快速失败,提前失败。

答案 1 :(得分:1)

抛出自己的异常,以防止外界看到异常的实际来源,从而获得有关您实施的信息。

您可以使用自定义消息或自定义异常抛出参数异常,以提供有关参数无效原因的更多详细信息。

答案 2 :(得分:0)

使用Exception 处理的目的是处理可能无法控制的异常。如果您计划将代码包装在try-catch块中,但 NullReferenceException 除外,那么您应该有适当的东西来处理这种类型的异常并执行与此相关的任何必要操作错误。

话虽如此,在您知道可能会出现会引发异常的错误的情况下,最好检查这种情况 - 并且根本不会抛出错误,而是优雅地处理它。否则你只是通过异常编码,这是一种反模式。

请记住,异常就是规则的例外情况,而不是对代码执行中可能出错的任何内容的全部内容。

答案 3 :(得分:0)

想象一个例外,就像一个男人跳出燃烧的房子并呼救:你不希望他们吓唬普通民众,但你确实希望他们通知合适的人做些关于火的事情。 考虑到这一点:

1)如果你在DoSomething中有问题并且你知道如何解决它 - 你不需要例外:只需将其修复到DoSomething中。

2)如果DoSomething在处理问题时遇到问题(错误的属性,资源不可用等等) - 使用异常来解决问题并在可以进行此类处理的级别上处理它。

3)如果DoSomething以某种方式搞砸你无法以任何方式影响(比如文件系统崩溃和IO异常无处不在) - 只需捕获异常,记录并优雅地关闭 - 至少这种情况看起来不像是内爆。

答案 4 :(得分:0)

一组情况,你不应该提前尝试检测错误情况,而不仅仅是让代码失败,这是外部资源依赖于外部资源的情况。你的代码控制。例如。处理网络,文件系统等的任何事情。

任何这些问题都是检查代码可以成功,然后实际操作仍然失败。你通过添加检查代码所做的就是增加了你编写的代码量 - 你仍然必须编写代码来处理实际的失败无论如何

答案 5 :(得分:0)

Eric Lippert has a great article on Exception.

请点击链接。它是如何处理异常的非常好的资源。

根据经验,尽量避免异常,而不是试图处理异常。并没有抓住所有的例外。我在您的代码中看到了Catch(Exception ex)。捕获您可以处理的异常。获得OutofMemoryExceptionThreadAbortException

后,您无能为力

我同意Henk Holterman