Question

更新：这里的错误代码不是函数的返回值。实际上我不讨论使用异常或错误代码进行错误处理。我试图弄清楚，使用什么模式来组织错误。我真正在做的就是在Windows蓝屏上显示错误代码。回到过去的时候，当您的Windows崩溃时，您可以在蓝屏上看到错误代码，使用该代码，您可以通过查找MS的文档来确定正在发生的事情。在我的系统中，有许多插件由不同的人贡献，可能彼此不认识。如果我允许他们定义他们的错误代码。它主要是两个插件的错误代码可能会发生冲突。

=============================================== ================================================= < / p>

我想设计一个可扩展的错误代码系统，允许插件定义自己的错误代码。基本思路是：

系统有一系列保留错误代码
插件可以选择系统未使用的范围，然后在该范围内创建其错误代码。然而，问题是插件彼此不了解（因为插件可能由不同的人编写并根据用户的喜好安装到系统中）。所以他们的错误代码范围可能会发生冲突。

这项要求有什么好的做法吗？我谷歌很多，但令我惊讶的是，很少有文章谈论在生产软件中设计错误代码。大多数帖子都关注异常与错误代码。

而且，是否有任何良好的模式可以显示产品中的错误，用户可以弄清楚发生了什么？我的基本想法是向用户显示错误，其中包含错误代码，描述和详细信息。用户可以点击错误代码然后我会告诉他正确的解决方案

Answer 1

不知道你正在构建的插件系统是什么......

插件是否应该负责将此信息提供给主机应用程序？为什么不在插件上执行操作的结果包含这些项？这样你的主机应用程序就不关心插件特定的实现细节，只是某些东西是好的......

const int OP_SUCCESS = 0;

// structure returned for plugin ops
struct OperationResponse {
    int code; // any other value than OP_SUCCESS is plugin-defined
    string message; // operation optional message, even if success
    // other fields
};

所以每次调用插件都会：

OperationResponse r = plugin.DoOperation();

if (r.code != OP_SUCCESS) {
    // do something with r.message and other fields
}

Answer 2

对于您的应用程序抛出的每个异常，您将其插入到数据库中，您的错误代码是该记录的ID，这是用户看到的内容。显然，同样的异常会获得相同的id。您需要的插件信息存储在DB

中

如何设计可扩展的错误代码？

2 个答案: