要在Python异常消息中放入详细信息的约定？

Question

我正在尝试确定如何编写异常消息的一些指导原则。

例如，让我们假设一个假设的函数必须接收一个恒定的字节数（作为bytes对象），我们用[1, 2, 3]来调用它。以下是所有可能的例外情况：

1. TypeError
2. TypeError: argument must be 16 bytes
3. TypeError: argument must be 16 bytes; got 'list'
4. TypeError: argument must be 16 bytes; got 'list' [1, 2, 3]

一般来说，我觉得这条信息应该总能解释一下未达到的条件，但我想知道要包含多少关于违规物品的信息。

是否有关于此主题的指南？

Answer 1

很棒的问题！

当我通常创建自定义异常时，我通常会查看通常详尽无遗的Python集。

现在关于提供多少细节的问题，我不会让它们过于具体，因为你不知道会触发它们或导致它们的原因。

例如：

TypeError: unsupported operand type(s) for +: 'int' and 'str'

足以让我知道+运算符不受支持，我不需要知道该字符串包含的内容。

所以在你的例子中，前两个完全没问题，其中两个是过度的IMO。

古德勒克。

Answer 2

我没有太多关于“成熟的成语”链接给你的方式，但这里是我的2¢：

你的目标是为那些冒充异常（即可能不是你和/或将来很远）的可怜的傻瓜提供足够的信息来理解这个问题，并希望能够解决它。

信息通过以下几种方式传达：

• 堆栈追踪 - 你可以免费获得。
• 异常类型 - 选择正确的类型有一些技巧，并决定何时适合制作更具体的异常类型。
• 消息 - 您要问的部分。

您还应该考虑：

• 上下文 - 如何使用此异常？您希望获得最大可能信息是一个严重错误，还是客户端可能希望在其代码中处理的瞬态条件，并且调试信息不​​是那么重要？如果您的例外可能由客户端代码处理，您可能希望将您的信息放入一种易于机器读取的格式，而不是文本消息。例如，有一个错误代码枚举字段。

但一般情况下，我认为最好问问自己：“如果我在生产代码中遇到此异常，我想要哪些信息可供我使用？”

就个人而言，在你给出的例子中，我每次都会选择（4）。我认为这不是太多的信息。你的例外看起来似乎应该永远不会发生，如果确实发生了，你想知道究竟出了什么问题。

如果你遗漏了信息，如（1-3）所示，你提供了一个混淆真实情况的机会。

不要在消息中提供冗余信息 - 不要仅仅为了它而详细。但为了未来的维护者的利益而传达所有相关信息。