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

我没有太多的“既定习惯用法”链接可供您参考，但以下是我的2美分：

您的目标是让遇到异常的可怜的sap（即，可能不是您和/或将来很长的时间）有足够的信息来理解问题，并希望能够解决它。在

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

• 堆栈跟踪-这是免费的。在
• 异常类型-选择正确的类型并决定何时创建更具体的异常类型是一种艺术。在
• 留言-你要问的部分。在

您还应考虑：

• 上下文-如何使用此异常？这是一个关键性的错误，你想要尽可能多的信息，还是这是一个暂时的情况，客户端很可能希望处理他们的代码，而调试信息不是那么重要？如果异常很可能由客户机代码处理，那么您可能希望将您的信息转换为易于机器读取的格式，而不是文本消息。例如，有一个错误代码枚举字段。在

但一般来说，我认为最好问问自己：“如果我在生产代码中遇到了这个异常，我想要什么信息可以提供给我？”在

就个人而言，在你给出的例子中，我每次都会选择选项（4）。我不认为这是太多的信息。你的异常看起来像是不应该发生的事情，如果它真的发生了，你想知道到底是什么出了问题。在

如果你漏掉了信息，如（1-3）所示，你就有机会混淆到底发生了什么。在

不要在消息中提供多余的信息-不要只是为了它而冗长。但是，为了未来的维护人员的利益，交流所有相关的信息。在

Answer 2

好问题！在

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

至于提供多少细节的问题，我不会说得太具体，因为你不知道什么会触发或导致它们。在

例如：

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

它的描述性足以让我知道+运算符不受支持，我不需要知道字符串包含什么。在

所以在你的例子中，前两个很好，第二个在我看来是太过分了

祝你好运。在