The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
我一遍又一遍地重复同样的错误。所以现在是时候停下来制定规则，防止这种情况再次发生了。这个错误并不致命，但非常令人烦恼。当我查看生产日志时，经常会看到类似于“文件不存在”的信息，然后我会问自己：什么文件？它应该存在在哪里？服务器试图对其执行什么操作？在崩溃前的一秒钟发生了什么？日志中没有答案，这完全是我的错。我要么1）不重新抛出异常，要么2）重新抛出异常时没有提供上下文。两者都是错误的。
代码可能如下所示：
它也可能看起来像这样：
这两个例子展示了一种不足的处理涉及异常和报告异常的方式。出了什么问题呢？异常信息不够详尽。它们只是简单地没有包含来自异常发生地点的任何信息。
以下是它们应该如何显示的样子：
而第二个例子应该是这样的：
看到区别了吗？这段代码看起来可能是多余的，但实际上并不是。当然，在我写这些代码的时候，并不真正关心日志和异常。我也不指望这个文件会不存在。
应该有一个规则：每次抛出或重新抛出时，异常信息必须尽可能详细地描述问题。
当然，我们不能忘记安全性，并且不要将任何敏感信息（如密码、信用卡号等）放入异常信息中。除此之外，尽可能多的信息必须暴露给更高级别的异常捕获器。
抛出异常实际上是将问题升级到更高级别的管理层面。想象一下，我的老板要求我安装一个新的服务器。几个小时后，我回来告诉他：“我失败了，对不起。”这听起来很奇怪。他会要求更多的细节。我为什么失败了？到底出了什么问题？是否可以用其他方式完成？等等。
这样的代码实际上是对客户的不尊重的标志。
我需要更加详细和具体地说明。
而且我并不是唯一犯这个错误的人。我到处都看到这个问题，它真的让调试变得困难，特别是在生产环境中，几乎不可能立即重现问题。
因此，请在异常信息中更加详细地说明。我会在我的代码中做同样的事情。
在你离开之前，还有一件事。在大多数面向对象编程语言中，异常都是未经检查的，这意味着捕获它们不是强制性的操作，不幸的是。尽管如此，我建议你始终捕获、添加上下文并重新抛出所有异常。这可能看起来纯粹是噪音，但事实并非如此！只需将你的方法变得更小，并确保所有传出异常都有足够的关于其来源的信息。这将对你自己和其他人都大有裨益。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 09:51
