为什么将exception.printStackTrace（）视为不良做法？

  • Z时代
  • 2024-01-10
  • 分类：问答

有一个很大的材料了有这表明印刷异常的堆栈跟踪是不好的做法。

例如从Checkexp中的RegexpSingleline检查：

可以使用此检查来查找常见的不良做法，例如调用ex.printStacktrace（）

但是，我正在努力寻找能够给出正当理由的任何地方，因为肯定可以使堆栈跟踪对于跟踪导致异常的原因非常有用。我知道的事情：

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

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

  3. 许多日志记录框架会为你打印堆栈跟踪（我们不会，也不行，我们无法轻松更改它）

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

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

回答：

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

  • 调用System.setErr()会更改所指向的目的地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如果目标文件/设备相同，则还需要同步），这对于支付日志文件的完整性来说是一笔不小的代价。举个例子，ConsoleHandlerand StreamHandler类负责在java.util.logging; 提供的日志记录工具中将日志记录追加到控制台。发布日志记录的实际操作是同步的-尝试发布日志记录的每个线程也必须获得与该日志记录关联的监视器上的锁StreamHandler实例。如果希望使用System.out/保证具有非交错日志记录System.err，则必须确保相同-消息以可序列化的方式发布到这些流中。

考虑到以上所有内容以及在Throwable.printStackTrace()实际中非常有用的非常受限制的场景，通常会发现调用它是一种不好的做法。

扩展前面段落之一中的参数，将它Throwable.printStackTrace与写入控制台的记录器结合使用也是一个糟糕的选择。部分原因是由于记录器将在另一个监视器上进行同步，而你的应用程序（可能，如果你不想插入日志记录）将在另一个监视器上进行同步。当你在应用程序中使用两个写入相同目的地的不同记录器时，该参数也适用。

以上是 为什么将exception.printStackTrace（）视为不良做法？ 的全部内容， 来源链接： utcz.com/qa/410545.html

回到顶部