.net - 从您的方法返回异常是不好的做法

Question

我的同行编写的许多代码库方法都执行自己的错误处理，通常是通过捕获、通知和记录。

在这些情况下，方法返回一个 bool 值，指示成功或失败。

但有时，如果一个方法失败，我希望调用代码知道原因，并且返回一个 bool 值是不够的。

解决这个问题的一种方法是在方法中保留错误处理，但使方法无效，并让方法抛出它们的异常。

但是，最近我养成了在适当的方法中返回异常的习惯，通常是可能无效的操作方法，但我想知道操作的状态。

与 void 方法抛出异常相比，返回异常的优点是我认为它使其他程序员更容易使用您的库，并且，更重要的是，这意味着您可以安全地调用该方法，而不必担心捕获异常 。

例如，如果方法只是 void，则程序员应该处理成功或失败可能不会立即显而易见。

但是，如果这些方法专门指定了返回类型 Exception，那么您就知道可以根据需要检查成功或失败。但这也意味着如果您不想捕获错误，则无需担心。

那有意义吗？也许我没有使用最好的例子，但一般来说，返回异常可以吗，还是有更好的模式？

更新

哇，压倒性的结果是没办法 .我是这么想的。我必须说，这样做(返回异常)有点 解决了一个问题，但确实感觉不对。

因此，从您的一些答案来看，这些特定场景(复杂类，或具有一个或多个外部依赖项(即 Web 服务)的类)的最佳解决方案似乎是自定义结果类？

更新:

我真的很感激所有的意见，我正在阅读所有内容，并且我正在仔细考虑所有的输入。

目前我更喜欢有一个 void 方法，抛出异常，然后在外面捕获它们......那更好吗？

Answer 1

如果你的意思是......

public Exception MyMethod( string foo )
{
   if( String.IsNullOrEmpty() )
   {
      return new ArgumentNullException( "foo" );
   }
}

... 而不是 ...

public void MyMethod( string foo )
{
   if( String.IsNullOrEmpty() )
   {
      throw new ArgumentNullException( "foo" )
   }
}

那么绝对不行，那样做是不行的。您将完全重新发明异常的目的并将其用作结果。这里有一些标准 best practices .

另一个不这样做的好理由是标准委托(delegate)将不再匹配您的方法签名。因此，例如，您不能使用 Action<string>在 MyMethod 上不再需要使用 Func<string,Exception>反而。

@Andy，每条评论，回答太长了:不是真的。不要太在意来电者。无论如何，他的设计应该是防御性的。想想异常的语义......“除非有人知道如何解决这个问题，否则这个应用程序的执行将在这里停止。”如果你能解决问题，你应该解决它。如果你不能，你必须记录它并把它扔到一个新的水平，因为他们可能知道该怎么做。

你应该处理你能处理的东西，扔掉你不能处理的东西。根据定义，调用堆栈上的人比你拥有更广阔的世界观。您的应用程序需要具有弹性，能够处理异常并继续运行。他们这样做的唯一方法是防御性编码，并将问题提升到更高级别的信息，看看是否可以做任何事情。

最终如果答案是“否”，那么将问题记录到它可以理解，做一个好公民，优雅地终止应用程序，然后再活下去。不要自私，并尝试为您的来电者隐藏错误。保持防守，他也会这样做。 :)

查看 Enterprise Library Exception handling block .它认为他们真正阐明了如何处理整个架构中的异常的伟大愿景。