您对异常消息使用什么样式

本文关键字：什么 什么样 样式 异常 消息 | 更新日期: 2023-09-27 17:47:49

在编写抛出我在这里询问的异常的代码时，我走到了消息的末尾，并在标点处停顿了一下。我意识到，我抛出的几乎每一条异常消息都可能有一个！在某处

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

写异常消息时，您的语气是什么？当浏览日志时，你是否发现任何特定风格的消息实际上比另一种更有帮助？

您对异常消息使用什么样式

系统消息中的对话语气使软件看起来不专业且草率。感叹点、侮辱和俚语在经过修饰的异常消息中并没有真正的位置。

此外，我倾向于在Java中对运行时异常和检查异常使用不同的样式，因为运行时异常是针对犯错误的程序员的。由于运行时异常可能会显示给最终用户，所以我仍然"保持干净"，但它们可能会更简洁和神秘一些。检查的异常消息应该更有帮助，因为如果您描述问题（例如，找不到文件、磁盘已满、没有到主机的路由等），用户可能会解决问题

在信息的异常上没有特定字段的情况下，有一件事是有用的，那就是违规数据：

throw new IndexOutOfBoundsException("offset < 0: " + off);

我试图反映我所编码的框架的语气、语法和标点符号风格。你永远不知道这些消息中的一条何时会真正出现在客户或用户面前，所以我保持一切专业、不带评判性和针对性，以便进行故障排除——而不会过于具体，以至于泄露代码中的任何安全问题。

我在所有字符串（UI和异常）中都避免使用感叹号，就像瘟疫一样，除了在单元测试中（局部）。

只是事实。包括调试时可能需要的所有信息，但仅限于此。

我唯一会在异常消息中添加感叹号的时候是，如果它表明发生了非常非常奇怪的事情。大多数错误并不是真的很奇怪，只是不正确的环境、用户错误或简单的编程错误的产物。

承担责任，即使这确实是用户的错，也是我见过的最好的选择。

类似于"我找不到你想要的文件，你能检查一下我是否正确吗？"或"出了问题。不知道怎么回事，但我唯一能解决的方法是停止。请重新启动我。"

简洁、详细且几乎没有冗余的信息（即ArgumentNullException显然涉及null）。

但这是我读过的最好的一段时间了，第一个答案。

我不会太多使用感叹号。他们表达得太多了，想想"驱动器里没有磁盘！"可以读成"你这个疯狂的用户，驱动器里没有硬盘。"；）

我认为抛出包含国际化文本的异常是明智的。你永远不知道谁会使用你的代码，捕捉你的异常并向用户显示文本。那就是：

throw new MagicalException(getText("magical.exception.text"));

我还建议在抛出异常时包装底层异常（如果有）。这确实有助于调试。

不要认为运行时异常不会被用户看到。如果你正在记录到一个文件附加程序，一些好奇的用户可能会打开日志，窥探你的脏秘密。

我发现最有用的消息是：

  • 一个一致的格式，使您更容易理解他们告诉您的内容
  • 时间戳，这样您就可以了解程序的动态
  • 错误的简要摘要。如果您提供技术支持，请添加错误代码以快速识别
  • 错误的解释，区分无效用户输入和编码错误
  • 详细信息，包括所涉及的代码行或值

最重要的是：

  • 它们告诉用户如何解决问题

示例：

commit.c第42行出现错误203（超时）：无法将用户"Linus"的薪资数据保存到位于"10.10.1.21"的数据库中1500米之后。验证数据库地址和登录凭据

最难吸取的教训之一是，用户对代码内部的兴趣远不如对完成工作的兴趣让他们尽可能轻松地完成他们的工作，你就为你的软件增加了巨大的价值。

我倾向于将异常消息处理成异常本身。例如，file_not_found应显示"找不到文件"。只有在用户无法理解的情况下，才应包含特定数据；在这种情况下，用户知道文件名，所以我不添加这些数据。格式化可以通过任何输出信息来完成，如果需要的话，所以我尽量让它们对重新格式化友好。

礼貌、简洁、简单、具体。通常，在消息中包含状态值是有帮助的。

相关文章：