7

我正在尝试确定一些有关如何编写异常消息的准则。

例如，让我们假设一个必须接收恒定字节数（作为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]

一般来说，我觉得消息应该总是解释不满足的条件，但我对包含多少关于违规对象的信息持观望态度。

有没有关于这个主题的指导方针？

4

2 回答 2

2

好问题！

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

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

例如：

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

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

所以在你的例子中，前两个非常好，后两个是过度杀伤 IMO。

祝你好运。

于 2013-09-16T18:27:00.133 回答
1

我没有太多“已建立的成语”链接可以给你，但这是我的 2 美分：

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

信息通过异常以多种方式传达：

  • 堆栈跟踪 - 您可以免费获得它。
  • 异常类型 - 选择正确的类型并决定何时创建自己的更具体的异常类型需要一些技巧。
  • 消息 - 您要询问的部分。

您还应该考虑：

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

但一般来说，我认为最好问问自己：“如果我在生产代码中遇到这个异常，我希望我可以获得哪些信息？”

就个人而言，在您给出的示例中，我每次都会选择选项（4）。我不认为这是太多的信息。您的异常似乎几乎永远不会发生，如果确实发生了，您想确切地知道出了什么问题。

如果您遗漏信息，如 (1-3) 中所示，您提供了一个混淆真实情况的机会。

不要在消息中提供多余的信息——不要仅仅为了它而冗长。但是为了那些摸不着头脑的未来维护者的利益，交流所有相关信息。

于 2013-09-16T21:08:10.093 回答