it-swarm.cn

为什么exception.printStackTrace()被认为是不好的做法?

有一个 很多 / 材料 out 那里 这表明打印异常的堆栈跟踪是不好的做法。

例如。来自Checkstyle的RegexpSingleline检查:

这个检查可用于查找常见的不良做法,例如调用ex.printStacktrace()

但是,我很难找到任何能够提供正确理由的地方,因为堆栈跟踪在跟踪导致异常的原因时非常有用。我所知道的事情:

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

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

  3. 许多日志记录框架将为您打印堆栈跟踪(我们的不会也不会,我们无法轻易更改它)

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

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

116
Chris Knight

Throwable.printStackTrace()将堆栈跟踪写入System.err PrintStream。可以重定向System.err流和JVM进程的基础标准“错误”输出流

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

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

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

在大多数情况下,不满足上述条件。人们可能不知道在JVM中运行的其他代码,并且无法预测日志文件的大小或进程的运行时间,并且精心设计的日志记录实践将围绕编写“机器可解析”日志文件(a在已知目的地的记录器中的优选但可选的特征,以帮助支持。

最后,应该记住Throwable.printStackTrace()的输出肯定会与写入System.err的其他内容交错(如果两者都被重定向到同一文件/设备,甚至可能是System.out)。这是一个必须处理的烦恼(对于单线程应用程序),因为异常数据在这样的事件中不容易解析。更糟糕的是,多线程应用程序极有可能产生非常混乱的日志,因为Throwable.printStackTrace() 不是线程安全的

当多个线程同时调用Throwable.printStackTrace()时,没有同步机制来将堆栈跟踪的写入同步到System.err。解决这个问题实际上需要您的代码在与System.err关联的监视器上进行同步(如果目标文件/设备相同,也需要System.out),这对于支持日志文件的健全性来说是相当沉重的代价。举个例子,ConsoleHandlerStreamHandler类负责在Java.util.logging提供的日志记录工具中将日志记录附加到控制台;发布日志记录的实际操作是同步的 - 每个尝试发布日志记录的线程也必须获取与StreamHandler实例关联的监视器上的锁。如果您希望使用System.out/System.err具有相同的非交错日志记录保证,则必须确保相同 - 消息以可序列化的方式发布到这些流。

考虑到上述所有情况,以及Throwable.printStackTrace()实际上非常有用的非常有限的情况,通常会发现调用它是一种不好的做法。


扩展前面段落中的一个参数,将Throwable.printStackTrace与写入控制台的记录器结合使用也是一个不好的选择。这部分是由于记录器将在不同的监视器上同步的原因,而您的应用程序(可能,如果您不希望交错的日志记录)在不同的监视器上同步。当您在应用程序中使用两个写入同一目标的不同记录器时,该参数也很有用。

111
Vineet Reynolds

你在这里触及多个问题:

1)堆栈跟踪永远不应对最终用户可见(出于用户体验和安全目的)

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

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

2)生成堆栈跟踪是一个相对昂贵的过程(虽然在大多数“异常”情况下不太可能成为问题)

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

3)许多日志记录框架将为您打印堆栈跟踪(我们的不会也不会,我们无法轻易更改)

很好的一点。这里的主要问题是:如果框架为您记录异常,则不执行任何操作(但请确保它执行!)如果您想自己记录异常,请使用日志框架,如 LogbackLog4J ,不要将它们放在原始控制台上,因为它很难控制它。

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

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

再次:正确记录SQLException使用完整的堆栈跟踪,使用日志框架)并显示Nice:“_(抱歉,我们目前无法处理您的请求”消息。您是否真的认为用户对原因感兴趣?你有没有看过StackOverflow错误屏幕?它非常幽默,但没有透露任何细节。但它确保用户将调查问题。

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


包装: always log exception(最好使用 logging framework ),但不要将它们暴露给最终用户。仔细考虑GUI中的错误消息,仅在开发模式下显示堆栈跟踪。

32
Tomasz Nurkiewicz

第一件事 printStackTrace() 并不像你说的那样昂贵,因为当自己创建异常时,堆栈跟踪被填充。

我们的想法是通过记录器框架传递任何记录日志,以便可以控制日志记录。因此,不要使用printStackTrace,只需使用像Logger.log(msg, exception);这样的东西。

17
Suraj Chandran

打印异常的堆栈跟踪本身并不构成不好的做法,但是 only 在发生异常时打印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,用于处理Thread.sleep抛出的InterruptedException。)

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

11
coobird

我认为你的理由清单非常全面。

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

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

上面代码的问题是处理包含_ = printStackTrace调用的 完全 :异常处理不正确,也不允许转义。

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

最后,在较轻松的音符上, 上帝的完美例外

9
NPE

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

4
Oh Chin Boon

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

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

3
Hajo Thelen

这是不错的做法,因为PrintStackTrace()的某些内容是“错误的”,但因为它是'代码味道'。大多数时候PrintStackTrace()调用都在那里因为某人未能正确处理异常。一旦以正确的方式处理异常,您通常就不再关心StackTrace了。

此外,在stderr上显示堆栈跟踪通常仅在调试时有用,而不是在生产中,因为stderr通常无处可去。记录它更有意义。但是,仅仅通过记录异常来替换PrintStackTrace()仍然会使您失败但仍然保持运行的应用程序。

3
AVee

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

而不是你需要尝试从异常中恢复(如果它是可恢复的),或者抛出RuntimeException,或者将异常冒泡到调用者以避免静默崩溃(例如,由于不正确的记录器配置)。

0
gumkins