代码之家 › 专栏 › 技术社区 › BCS

内部错误标记

error-reporting user-experience error-handling

BCS · 技术社区 · 16 年前

理论上,最终用户不应该看到内部错误。但在实践中,理论和实践是不同的。所以问题是要向最终用户展示什么。现在,对于完全非技术性的用户,您希望尽可能少地显示(“ 单击此处提交错误报告 “类似的事情”),但是对于更高级的用户,他们会想知道是否有一个解决方案,是否已知一段时间,等等,所以你想包括一些还有一些关于问题的信息。

实现这一点的经典方法是使用文件名:行号断言,或者使用相同的堆栈跟踪。现在这对开发人员很好,因为它指出了问题所在;但是它对用户有一些明显的缺点,特别是它非常神秘(例如不友好),代码更改会更改错误消息(谷歌搜索错误仅适用于此版本)。

我有一个计划,我正计划在哪里写作,我想解决这些问题。我想要的是一种将唯一标识附加到每个断言的方法,这种方法使得在断言周围编辑代码不会改变它。(例如,如果我剪切/粘贴到另一个文件,我希望显示相同的信息)有什么想法吗?

我想的一个方法是对错误进行枚举,但是如何确保它们从未在多个地方使用过?

(注:对于这个问题, 我是只查看由编码错误引起的错误。不是那些可以合法发生的事情,比如糟糕的投入。奥托赫,这些错误可能对整个社会有一定的意义。)

(注2:所讨论的程序是在用户系统上运行的命令行应用程序。但同样,这只是我的情况。)

(注3:目标语言为 D 和 I'm very willing 潜入 meta-programming . 其他语言的答案不受欢迎!)

(注4:我明确地不想使用实际的代码位置,而是使用某种符号名称来表示错误。这是因为如果代码实际上是以任何方式更改的,那么代码位置会发生更改。)

3 回复 | 直到 16 年前

Ned Batchelder 16 年前

编写一个脚本来grep您的整个源代码树以使用这些错误代码,然后抱怨是否有重复的代码。作为单元测试的一部分运行该脚本。

Jonathan Leffler 16 年前

有趣的问题。我多次使用的一个解决方案是:如果这是一个致命错误(例如,非致命错误应该给用户纠正输入的机会),我们将生成一个包含大量相关信息的文件:请求变量、头、内部配置信息和完整的回溯信息,以备以后调试。我们将其存储在一个文件中,该文件具有生成的唯一文件名(并以时间作为前缀)。

对于用户,我们提供了一个页面,解释发生了一个不可恢复的错误,并要求他们包含文件名作为参考,如果他们想报告错误。使用来自冲突请求上下文的所有这些信息进行调试要容易得多。

在PHP中,debug_backtrace()函数对此非常有用。我相信有一个和你的平台相当的平台。

还要记住发送相关的HTTP头:可能是:HTTP/1.1500内部服务器错误

考虑到错误报告文件的合理格式,还可以分析用户未报告的错误。

John Dibling 16 年前

我对你的目标语言一无所知,但这是一个有趣的问题,我已经考虑过了,我想加上我的两分钱。

我一直认为,对于开发人员来说,针对硬错误和内部错误的消息应该是尽可能有用的,以便快速识别和修复问题。大多数用户甚至不会看到这个错误消息,但是高度复杂的最终用户(可能是技术支持人员)通常会非常清楚问题所在,甚至通过查看高度详细的错误消息来提出新的解决方法。关键是要让这些错误信息详细而不含糊,这不仅仅是一门科学,更是一门艺术。

使用进程外COM服务器的Windows程序示例。如果主程序尝试从COM服务器实例化对象,但失败并显示错误消息:

“警告:无法实例化实用程序对象:错误'类不是已在“CoCreateInstance”中注册“

99%的用户会看到并认为它是用希腊语写的。技术支持人员可能会很快意识到他们需要重新注册COM服务器。开发人员会知道到底出了什么问题。

为了将一些上下文信息与断言相关联,在我的C++代码中,我经常使用一个简单的字符串,用该方法的名称,或者其他明确的错误发生的地方(我用你没有问的语言回答):

int someFunction()
{
  static const std::string loc = "someFunction";
  :  :
  if( somethingWentWrong )
  {
    WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject:  Error 'Class Not
    Registered' in 'CoCreateInstance);
  }
}

…产生:

警告[somefunction]:无法实例化实用程序对象:错误中的“类未注册” '共同创造