Java或C＃中异常管理的最佳实践[关闭]

Question

我一直在决定如何在我的应用程序中处理异常。

如果我的异常问题来自1）通过远程服务访问数据或2）反序列化JSON对象。 不幸的是，我不能保证这些任务中的任何一个都成功（切断网络连接，不正确的JSON对象，这是我无法控制的）。

因此，如果我遇到异常，我只需在函数内捕获它并返回FALSE给调用者。 我的逻辑是，所有调用者真正关心的是任务是否成功，而不是为什么它不成功。

这是典型方法的一些示例代码（在JAVA中）

public boolean doSomething(Object p_somthingToDoOn)
{
    boolean result = false;

    try{
        // if dirty object then clean
        doactualStuffOnObject(p_jsonObject);

        //assume success (no exception thrown)
        result = true;
    }
    catch(Exception Ex)
    {
        //don't care about exceptions
        Ex.printStackTrace();
    }
    return result;
}

我认为这种方法很好，但我真的很想知道管理异常的最佳实践是什么（我应该在调用堆栈中一直冒出异常吗？）。

总结关键问题：

1. 是否可以捕获异常但不会冒泡或正式通知系统（通过日志或通知用户）？
2. 对于不会导致所有需要try / catch块的异常的最佳实践有哪些？

跟进/编辑

感谢所有反馈，在网上找到了一些关于异常管理的优秀来源：

• 异常处理的最佳实践| 奥莱利媒体
• .NET中的异常处理最佳实践
• 最佳实践：异常管理 （文章现在指向archive.org副本）
• 异常处理反模式

似乎异常管理是根据上下文而变化的事情之一。 但最重要的是，人们应该如何管理系统中的异常。

另外注意通过过多的尝试/捕获代码腐烂或不给予例外它的尊重（例外是警告系统，还需要警告什么？）。

此外，这是m3rLinEz的一个很好的选择评论。

我倾向于同意Anders Hejlsberg和你的看法，大多数来电者只关心操作是否成功。

从这个评论中，它提出了一些在处理异常时要考虑的问题：

• 抛出此异常有什么意义？
• 处理它有什么意义？
• 呼叫者是否真的关心异常，还是只关心呼叫是否成功？
• 是否强制调用者管理潜在的异常优雅？
• 你是否尊重这种语言的含义？
  • 你真的需要返回像布尔这样的成功标志吗？ 返回boolean（或int）更像是一种C心态而不是Java（在Java中你只是处理异常）。
  • 遵循与语言相关的错误管理结构:)！

Answer 1

对我来说，想要捕获异常并将它们转换为错误代码似乎很奇怪。 为什么在后者是Java和C＃中的默认值时，您认为调用者更喜欢错误代码而不是异常？

至于你的问题：

1. 您应该只捕获实际可以处理的异常。 在大多数情况下，捕获异常并不是正确的做法。 有一些例外（例如，线程之间的日志记录和编组异常），但即使对于这些情况，通常也应该重新抛出异常。
2. 你的代码中绝对不应该有很多try / catch语句。 同样，我们的想法是只捕获您可以处理的异常。 您可以包含一个最顶层的异常处理程序，将任何未处理的异常转换为对最终用户有用的东西，但是否则您不应该尝试捕获每个可能位置的每个异常。

Answer 2

这取决于应用和情况。 如果你构建一个库组件，你应该冒出异常，尽管它们应该被包装成与你的组件一起上下文。 例如，如果您构建一个Xml数据库并假设您正在使用文件系统来存储数据，并且您正在使用文件系统权限来保护数据。 您不希望冒出一个FileIOAccessDenied异常，因为它会泄漏您的实现。 相反，您将包装异常并抛出AccessDenied错误。 如果您将组件分发给第三方，则尤其如此。

至于是否可以吞下例外。 这取决于你的系统。 如果您的应用程序可以处理故障情况，并且通知用户失败的原因没有任何好处，那么请继续，尽管我强烈建议您记录失败。 我总是觉得很难打电话来帮助解决问题并发现他们正在吞下异常（或者替换它并抛出新的异常而不设置内部异常）。

一般来说，我使用以下规则：

1. 在我的组件和库中，如果我打算处理它或基于它做某些事情，我只会捕获异常。 或者，如果我想在异常中提供其他上下文信息。
2. 我在应用程序入口点或尽可能高的级别使用常规try catch。 如果异常到达此处，我只需记录它并让它失败。 理想情况下，异常永远不会到达此处

我发现以下代码是一种气味：

try
{
    //do something
}
catch(Exception)
{
   throw;
}

像这样的代码没有任何意义，不应该包括在内。

Answer 3

我想就这个主题推荐另一个好的来源。 这是对C＃和Java，Anders Hejlsberg和James Gosling的发明者的访谈，分别是关于Java的Checked Exception的主题。

失败和例外

页面底部还有很多资源。

我倾向于同意Anders Hejlsberg和你的看法，大多数来电者只关心操作是否成功。

Bill Venners ：您提到了关于已检查异常的可扩展性和版本控制问题。 你能澄清这两个问题的含义吗？

Anders Hejlsberg ：让我们从版本开始，因为问题很容易在那里看到。 假设我创建了一个声明它抛出异常A，B和C的方法foo。在foo的第二个版本中，我想添加一些功能，现在foo可能会抛出异常D.这对我来说是一个彻底的改变。将D添加到该方法的throws子句中，因为该方法的现有调用者几乎肯定不会处理该异常。

在新版本中向throws子句添加新异常会破坏客户端代码。 这就像在界面中添加方法一样。 在发布接口之后，它实际上是不可变的，因为它的任何实现都可能具有您要在下一个版本中添加的方法。 所以你必须创建一个新的界面。 与异常类似，您可能必须创建一个名为foo2的全新方法，该方法会抛出更多异常，或者您必须在新foo中捕获异常D，并将D转换为A，B或C.

Bill Venners ：但是你不是在这种情况下破坏他们的代码，即使是在没有检查异常的语言中吗？ 如果foo的新版本将抛出一个客户应该考虑处理的新异常，那么他们的代码是不是因为他们在编写代码时没有预料到异常这一事实？

Anders Hejlsberg ：不，因为在很多情况下，人们并不关心。 他们不会处理任何这些例外情况。 它们的消息循环周围有一个底层异常处理程序。 那个处理程序只是打开一个对话框，说明出了什么问题并继续。 程序员通过在任何地方编写try finally来保护他们的代码，因此如果发生异常他们将正确退出，但他们实际上并不感兴趣处理异常。

throws子句，至少它在Java中的实现方式，并不一定会强制您处理异常，但如果您不处理它们，它会强制您确切地确认哪些异常可能会通过。 它要求您捕获声明的异常或将它们放在您自己的throws子句中。 为了解决这个问题，人们做了荒谬的事情。 例如，他们用“抛出异常”来装饰每个方法。 这完全打败了这个功能，你只是让程序员写了更多的gobbledy gunk。 这对任何人都没有帮助。

编辑：添加了有关转换的更多详细信息

Answer 4

检查异常通常是一个有争议的问题，特别是在Java中（稍后我将尝试为那些赞成并反对它们的人找到一些例子）。

根据经验，异常处理应该围绕这些准则，而不是特定的顺序：

• 为了可维护性，请始终记录异常，以便在您开始看到错误时，日志将帮助您指向错误可能已启动的位置。 永远不要离开printStackTrace()或类似的东西，很可能你的一个用户最终会获得其中一个堆栈跟踪，并且对于如何处理它几乎一无所知 。
• 捕获可以处理的异常，只有那些并处理它们 ，不要只是将它们抛到堆栈中。
• 总是捕获一个特定的异常类，通常你永远不应该捕获类型Exception ，你很可能会吞下其他重要的异常。
• 永远不会（永远）抓住Error !! ，意思是： 永远不要捕获Throwable因为Error是后者的子类。 Error是您很可能永远无法处理的问题（例如OutOfMemory或其他JVM问题）

关于您的具体情况，请确保调用您的方法的任何客户端都将收到正确的返回值。 如果某些内容失败，布尔返回方法可能会返回false，但请确保您调用该方法的位置能够处理该方法。

Answer 5

您应该只捕获可以处理的异常。 例如，如果您正在处理通过网络阅读并且连接超时而您获得异常，则可以再试一次。 但是，如果您正在通过网络阅读并获得IndexOutOfBounds异常，那么您实际上无法处理它，因为您没有（好吧，在这种情况下您不会）知道是什么导致它。 如果您要返回false或-1或null，请确保它是针对特定异常的。 当抛出的异常是堆内存不足时，我不希望我正在使用的库在网络读取时返回false。

Answer 6

例外是不属于正常程序执行的错误。 根据您的程序及其用途（即文字处理器与心脏监视器）的不同，您可能希望在遇到异常时执行不同的操作。 我使用的代码使用异常作为正常执行的一部分，它绝对是代码味道。

防爆。

try
{
   sendMessage();

   if(message == success)
   {
       doStuff();
   }
   else if(message == failed)
   {
       throw;
   }
}
catch(Exception)
{
    logAndRecover();
}

这段代码让我成了barf。 IMO你不应该从例外中恢复，除非它是一个关键程序。 如果你抛出异常，那么坏事就会发生。

Answer 7

以上所有内容似乎都是合理的，通常您的工作场所可能有政策。 在我们的位置，我们已经定义了Exception的类型： SystemException （未选中）和ApplicationException （已选中）。

我们已经同意SystemException不太可能被恢复，并且将在顶部处理一次。 为了提供进一步的上下文，我们的SystemException被扩展以指示它们发生的位置，例如RepositoryException ， ServiceEception等。

ApplicationException可能具有像InsufficientFundsException这样的业务含义，应该由客户端代码处理。

Witohut是一个具体的例子，很难评论你的实现，但我永远不会使用返回码，它们是一个维护问题。 您可能会吞下Exception，但您需要确定原因，并始终记录事件和堆栈跟踪。 最后，由于你的方法没有其他处理，它是相当冗余的（除了封装？），所以doactualStuffOnObject(p_jsonObject); 可以返回一个布尔值！

Answer 8

经过一番思考和查看代码之后，在我看来，你只是将异常重新抛出为布尔值。 您可以让方法通过此异常（您甚至不必捕获它）并在调用者中处理它，因为这是重要的地方。 如果异常将导致调用者重试此函数，则调用者应该是捕获异常的调用者。

有时会遇到您遇到的异常对调用者没有意义（即它是网络异常），在这种情况下，您应该将其包装在特定于域的异常中。

另一方面，异常表示程序中存在不可恢复的错误（即此异常的最终结果将是程序终止）我个人希望通过捕获它并抛出运行时异常来使其明确。

Answer 9

如果您要在示例中使用代码模式，请将其命名为TryDoSomething，并仅捕获特定的异常。

在为诊断目的记录异常时，还要考虑使用异常过滤器 。 VB具有Exception过滤器的语言支持。 Greggm博客的链接有一个可以在C＃中使用的实现。 异常过滤器具有比catch和rethrow更好的可调试性。 具体来说，您可以在过滤器中记录问题并让异常继续传播。 该方法允许附加JIT（即时）调试器以具有完整的原始堆栈。 重新抛出时重新抛出堆栈。

TryXXXX有意义的情况是当你包装第三方函数时抛出非真正异常的情况，或者在不调用函数的情况下很难测试。 一个例子是：

// throws NumberNotHexidecimalException
int ParseHexidecimal(string numberToParse); 

bool TryParseHexidecimal(string numberToParse, out int parsedInt)
{
     try
     {
         parsedInt = ParseHexidecimal(numberToParse);
         return true;
     }
     catch(NumberNotHexidecimalException ex)
     {
         parsedInt = 0;
         return false;
     }
     catch(Exception ex)
     {
         // Implement the error policy for unexpected exceptions:
         // log a callstack, assert if a debugger is attached etc.
         LogRetailAssert(ex);
         // rethrow the exception
         // The downside is that a JIT debugger will have the next
         // line as the place that threw the exception, rather than
         // the original location further down the stack.
         throw;
         // A better practice is to use an exception filter here.
         // see the link to Exception Filter Inject above
         // http://code.msdn.microsoft.com/ExceptionFilterInjct
     }
}

你是否使用像TryXXX这样的模式更像是一个风格问题。 捕捉所有异常并吞下它们的问题不是风格问题。 确保允许传播意外的异常！

Answer 10

我建议您从标准库中获取您正在使用的语言的提示。 我不能代表C＃，但让我们看看Java。

例如，java.lang.reflect.Array有一个静态set方法：

static void set(Object array, int index, Object value);

C方式将是

static int set(Object array, int index, Object value);

...返回值是成功指标。 但你不再在C世界了。

一旦你接受了异常，你应该通过将错误处理代码从核心逻辑中移开来发现它使代码更简单，更清晰。 目标是在一个try块中包含大量语句。

正如其他人所指出的那样 - 你应该尽可能具体地捕捉你遇到的异常。

Answer 11

如果您要捕获异常并返回false，则应该是一个非常特殊的异常。 你没有这样做，你抓住所有这些并返回虚假。 如果我得到一个MyCarIsOnFireException，我想马上知道它！ 我可能不关心的其他例外情况。 因此，对于某些异常（重新抛出，或者捕获并重新抛出一个更好地解释发生了什么的新异常）并且只为其他人返回false，你应该有一堆Exception处理程序，这些异常处理程序会说“whoa whoa some wrong”。

如果这是您要发布的产品，那么您应该在某处记录这些异常，这将有助于您将来调整。

编辑：关于在try / catch中包装所有内容的问题，我认为答案是肯定的。 代码中的异常应该是如此罕见，以至于catch块中的代码很少执行，根本不会达到性能。 例外应该是您的状态机损坏并且不知道该怎么做的状态。 至少重新抛出一个异常，解释当时发生的事情，并在其中发现捕获的异常。 “方法doSomeStuff（）中的异常”对于那些在度假（或新工作）时必须弄清楚它为何会破坏的人来说并不是很有帮助。

Answer 12

我的策略：

如果原始函数返回void我将其更改为返回bool 。 如果发生异常/错误则返回false ，如果一切正常则返回true 。

如果函数应返回某些内容，那么当发生异常/错误时返回null ，否则返回可返回项。

可以返回包含错误描述的字符串而不是bool 。

在每种情况下，在返回之前记录错误。

Answer 13

这里有一些很好的答案 我想补充一点，如果你最终得到像你发布的东西，至少打印超过堆栈跟踪。 说出你当时在做什么，以及Ex.getMessage（），给开发者一个战斗机会。

Answer 14

try / catch块形成嵌入在第一（主）集上的第二组逻辑，因此它们是一种很好的方法来敲出难以理解的，难以调试的意大利面条代码。

尽管如此，他们合理地使用了可读性的奇迹，但你应该遵循两个简单的规则：

• 在低级别使用它们（谨慎地）来捕获库处理问题，并将它们流回主逻辑流程。 我们想要的大多数错误处理应该来自代码本身，作为数据本身的一部分。 为什么要特殊条件，如果返回的数据不是特殊的？

• 在较高级别使用一个大型处理程序来管理代码中出现的任何或所有奇怪的条件，这些条件不是在低级别捕获的。 做一些有用的错误（日志，重启，恢复等）。

除了这两种类型的错误处理之外，中间的所有其余代码都应该是免费的，并且没有try / catch代码和错误对象。 这样，无论您在何处使用它，或者您使用它，它都可以简单地按预期工作。

保罗。

Answer 15

我的答案可能有点晚，但错误处理是我们可以随时改变和发展的事情。 如果你想阅读更多关于这个主题的内容，我在我的新博客中写了一篇关于它的文章。 http://taoofdevelopment.wordpress.com

快乐的编码。