138

有很多材料表明打印异常的堆栈跟踪是不好的做法。

例如，来自 Checkstyle 中的 RegexpSingleline 检查：

此检查可用于 [...] 查找常见的不良做法，例如调用 ex.printStacktrace()

但是，我很难找到任何给出合理理由的地方，因为堆栈跟踪对于追踪导致异常的原因肯定非常有用。我知道的事情：

  1. 最终用户不应该看到堆栈跟踪（出于用户体验和安全目的）

  2. 生成堆栈跟踪是一个相对昂贵的过程（尽管在大多数“异常”情况下不太可能成为问题）

  3. 许多日志框架会为您打印堆栈跟踪（我们的不会也不会，我们不能轻易更改）

  4. 打印堆栈跟踪不构成错误处理。它应该与其他信息记录和异常处理相结合。

还有哪些其他原因可以避免在代码中打印堆栈跟踪？

4

9 回答 9

136

Throwable.printStackTrace()将堆栈跟踪写入System.errPrintStream。JVM 进程的System.err流和底层标准“错误”输出流可以通过以下方式重定向

  • 调用System.setErr()which 会更改 指向的目的地System.err。
  • 或通过重定向进程的错误输出流。错误输出流可能被重定向到文件/设备
    • 其内容可能被人员忽略，
    • 文件/设备可能无法进行日志轮换，这意味着在归档文件/设备的现有内容之前，需要重新启动进程才能关闭打开的文件/设备句柄。
    • 或者文件/设备实际上丢弃了所有写入它的数据，就像/dev/null.

从上面推断，调用Throwable.printStackTrace()构成有效（不好/很好）的异常处理行为，只有

  • System.err如果您在应用程序的整个生命周期内没有被重新分配，
  • 如果您在应用程序运行时不需要日志轮换，
  • 如果应用程序的接受/设计的日志记录实践是写入System.err（以及 JVM 的标准错误输出流）。

在大多数情况下，上述条件都不满足。人们可能不知道在 JVM 中运行的其他代码，并且无法预测日志文件的大小或进程的运行时持续时间，并且设计良好的日志记录实践将围绕编写“机器可解析”的日志文件（一个记录器中更可取但可选的功能）在已知目的地，以帮助支持。

最后，应该记住， 的输出Throwable.printStackTrace()肯定会与写入的其他内容交错System.err（即使System.out两者都被重定向到同一个文件/设备）。这是一个必须处理的烦恼（对于单线程应用程序），因为在这种情况下，异常周围的数据不容易解析。更糟糕的是，多线程应用程序很可能会产生非常混乱的日志，因为Throwable.printStackTrace() 它不是线程安全的。

没有同步机制将堆栈跟踪的写入同步到System.err多个线程Throwable.printStackTrace()同时调用时。解决这个问题实际上需要您的代码在关联的监视器上同步System.err（并且System.out，如果目标文件/设备相同），这是为日志文件完整性付出的相当大的代价。举个例子，ConsoleHandler和StreamHandler类负责将日志记录附加到控制台，在提供的日志工具中java.util.logging；发布日志记录的实际操作是同步的 - 每个尝试发布日志记录的线程还必须获取与StreamHandler实例。System.out如果您希望使用/获得非交错日志记录的相同保证，System.err则必须确保相同 - 消息以可序列化的方式发布到这些流。

考虑到上述所有情况，以及Throwable.printStackTrace()实际有用的非常有限的场景，事实证明调用它是一种不好的做法。

扩展前一段中的论点，Throwable.printStackTrace与写入控制台的记录器结合使用也是一个糟糕的选择。这部分是由于记录器会在不同的监视器上同步，而您的应用程序会（可能，如果您不想要交错的日志记录）在不同的监视器上同步。当您在应用程序中使用两个不同的记录器写入同一目的地时，该论点也适用。

于 2011-09-19T12:09:35.140 回答
34

您在这里遇到了多个问题：

1）堆栈跟踪不应该对最终用户可见（出于用户体验和安全目的）

是的，它应该可以用来诊断最终用户的问题，但最终用户不应该看到它们，原因有两个：

  • 它们非常晦涩难读，应用程序看起来对用户非常不友好。
  • 向最终用户显示堆栈跟踪可能会带来潜在的安全风险。如果我错了，请纠正我，PHP 实际上在堆栈跟踪中打印函数参数 - 很棒，但非常危险 - 如果你在连接到数据库时遇到异常，你可能会在堆栈跟踪中做什么？

2）生成堆栈跟踪是一个相对昂贵的过程（尽管在大多数“例外”情况下不太可能成为问题）

在创建/抛出异常时会生成堆栈跟踪（这就是为什么抛出异常要付出代价），打印并不那么昂贵。实际上，您可以Throwable#fillInStackTrace()有效地覆盖自定义异常，从而使抛出异常几乎与简单的 GOTO 语句一样便宜。

3）许多日志框架会为您打印堆栈跟踪（我们的没有，也没有，我们不能轻易更改）

很好的一点。这里的主要问题是：如果框架为您记录异常，则什么也不做（但要确保它这样做！）如果您想自己记录异常，请使用Logback或Log4J等日志框架，不要将它们放在原始控制台上因为它很难控制。

使用日志框架，您可以轻松地将堆栈跟踪重定向到文件、控制台，甚至将它们发送到指定的电子邮件地址。使用硬编码printStackTrace()，您必须使用sysout.

4) 打印堆栈跟踪不构成错误处理。它应该与其他信息记录和异常处理相结合。

再次：SQLException正确记录（使用完整的堆栈跟踪，使用日志框架）并显示 nice：“抱歉，我们目前无法处理您的请求”消息。你真的认为用户感兴趣的原因吗？你见过 StackOverflow 错误屏幕吗？这很幽默，但没有透露任何细节。但是，它确保用户将调查问题。

但他会立即给您打电话，您需要能够诊断问题。所以你需要两者：正确的异常记录和用户友好的消息。

总结一下：总是记录异常（最好使用日志框架），但不要将它们暴露给最终用户。仔细考虑 GUI 中的错误消息，仅在开发模式下显示堆栈跟踪。

于 2011-09-19T10:23:10.377 回答
22

正如您所说，第一件事printStackTrace()并不昂贵，因为堆栈跟踪是在自身创建异常时填充的。

这个想法是通过记录器框架传递任何进入日志的内容，以便可以控制日志记录。因此，不要使用 printStackTrace，而是使用类似的东西Logger.log(msg, exception);

于 2011-09-19T10:18:34.867 回答
12

打印异常的堆栈跟踪本身并不构成不好的做法，但仅在发生异常时打印 stace 跟踪可能是这里的问题 - 通常，仅打印堆栈跟踪是不够的。

catch此外，如果块中执行的所有操作都是e.printStackTrace. 处理不当可能最多意味着一个问题被忽略，最坏的情况是程序继续在未定义或意外状态下执行。

例子

让我们考虑以下示例：

try {
  initializeState();

} catch (TheSkyIsFallingEndOfTheWorldException e) {
  e.printStackTrace();
}

continueProcessingAssumingThatTheStateIsCorrect();

在这里，我们希望在继续进行一些需要进行初始化的处理之前进行一些初始化处理。

在上面的代码中，应该已经捕获并正确处理了异常，以防止程序继续执行continueProcessingAssumingThatTheStateIsCorrect我们认为会导致问题的方法。

在许多情况下，e.printStackTrace()这表明某些异常正在被吞下，并且允许处理继续进行，就好像每次都没有发生问题一样。

为什么这成了一个问题？

糟糕的异常处理变得更加普遍的最大原因之一可能是由于 Eclipse 等 IDE 如何自动生成将执行e.printStackTrace异常处理的代码：

try {
  Thread.sleep(1000);
} catch (InterruptedException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
}

（上面是 Eclipse 实际try-catch自动生成的，用于处理InterruptedException抛出的Thread.sleep.）

对于大多数应用程序，仅将堆栈跟踪打印到标准错误可能是不够的。在许多情况下，不正确的异常处理可能会导致应用程序在意外状态下运行，并可能导致意外和未定义的行为。

于 2011-09-19T10:23:54.777 回答
10

我认为您列出的原因非常全面。

我不止一次遇到的一个特别糟糕的例子是这样的：

    try {
      // do stuff
    } catch (Exception e) {
        e.printStackTrace(); // and swallow the exception
    }

上面代码的问题在于处理完全由printStackTrace调用组成：异常没有真正正确处理，也不允许逃逸。

另一方面，作为一项规则，每当我的代码中出现意外异常时，我总是会记录堆栈跟踪。多年来，这项政策为我节省了大量的调试时间。

最后，在一个轻松的音符上，上帝的完美例外。

于 2011-09-19T10:24:53.527 回答
5

printStackTrace()打印到控制台。在生产环境中，没有人在看。Suraj 是正确的，应该将此信息传递给记录器。

于 2011-09-19T10:20:39.873 回答
5

这不是坏习惯，因为 PrintStackTrace() 有一些“错误”，而是因为它是“代码气味”。大多数时候 PrintStackTrace() 调用是因为有人未能正确处理异常。一旦以适当的方式处理异常，您通常就不再关心 StackTrace 了。

此外，在 stderr 上显示堆栈跟踪通常仅在调试时有用，而不是在生产中，因为 stderr 通常无处可去。记录它更有意义。但是仅仅用记录异常来替换 PrintStackTrace() 仍然会让你的应用程序失败但继续运行，就像什么都没发生一样。

于 2011-09-19T10:28:36.237 回答
4

在服务器应用程序中，堆栈跟踪会炸毁您的 stdout/stderr 文件。它可能会变得越来越大，并且充满了无用的数据，因为通常您没有上下文，也没有时间戳等。

例如使用 tomcat 作为容器时的 catalina.out

于 2011-09-19T10:19:28.070 回答
1

正如一些人在这里已经提到的那样，问题在于吞咽异常，以防您只是e.printStackTrace()在catch块中调用。它不会停止线程执行，并且会在 try 块之后继续正常情况。

取而代之的是，您需要尝试从异常中恢复（以防它可以恢复），或者抛出RuntimeException异常，或者将异常冒泡给调用者以避免静默崩溃（例如，由于不正确的记录器配置）。

于 2017-07-27T17:47:04.430 回答