为什么“登录和抛出”被认为是反模式?[关闭]

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (51)

这篇文章的讨论引发了这个问题,我没有收到任何好的答案。

为什么要记录你的异常,然后重新抛出它(当然要保留原始的堆栈跟踪),否则如果你不能处理它,这是一个坏主意?

提问于
用户回答回答于

我认为答案很大程度上是因为如果你无法处理它,为什么你会抓住它?为什么不让任何人可以处理它(或任何人无法处理它)记录下来,如果他们觉得这是值得登录的?

如果你捕获它并记录并重新抛出它,那么上游代码就无法知道你已经记录了异常,因此同一个异常可能会被记录两次。或者更糟糕的是,如果所有上游代码都遵循同样的模式,则可以将异常记录任意次数,代码中的每个级别都会记录一次,然后记录下来,然后再次丢弃。

也有人可能会争辩说,因为抛出异常和捕获异常是相对昂贵的操作,所有这些捕获和重新抛出都不会帮助运行时的性能。它在简洁或可维护性方面也不会帮助您的代码。

用户回答回答于

如果捕获并重新抛出异常的实体有理由相信它包含的信息不会在调用堆栈上进一步记录,那么Log-and-throw是一种很好的模式 - 至少不是以最期望的方式。这可能会发生几个原因:

  1. 该异常可能会在应用程序层边界被捕获并重新生成,并且可能包含特权信息。如果数据库层允许一个例外情况发生,例如“尝试将重复键'fnord'添加到'用户'字段以到达外部应用程序层(这可能会将其暴露给用户)可能对数据库的内部部分有用,以抛出这样的异常和应用程序接口来捕捉它,安全地记录它,并重新抛出一个稍微不那么具有描述性的异常。
  2. 例外情况可能是外层可能期望在没有日志记录的情况下处理,但内层可能知道外层不会这样做,这表明日志记录可能有用。作为一个粗略的例子,中间的应用程序层可能会被编程来尝试连接到一台服务器,如果这样做不起作用,请尝试另一台服务器。当服务器关闭以进行维护时,使用“连接失败”消息泛滥应用程序的日志可能没有帮助,尤其是因为从应用程序的角度来看,一切正常。将关于连接失败的信息转发到与服务器相关联的日志记录资源可能是有用的,该日志资源然后可以过滤日志以产生服务器何时升降的报告,而不是每个单个连接尝试的日志。

扫码关注云+社区

领取腾讯云代金券