3

我正在创建一个系统。我想知道的是，如果一个味精不受支持，它应该怎么做？我应该说不受支持的味精吗？我应该返回 0 还是 -1？或者我应该设置一个 errno (base->errno_)。有些消息我不关心是否有错误（例如 setBorderColour）。其他我会（添加文本或如果我创建保存 cmd 则可能保存）。

我想知道 1) 快速编码 2) 调试 3) 扩展和维护的最佳方法是什么。我可能会进行第三次调试，它很难调试 ATM，但那是因为有很多我没有填写的缺失代码。实际的错误并不难纠正。让用户知道有错误的最佳方法是什么？

该系统的工作原理与此类似，但并不完全相同。这是 C 风格，mycode 有一堆内联函数，将 settext(const char*text){ 包装到 msg(this, esettext, text)

Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);
4

4 回答 4

8

通常，如果它是 C++，则更喜欢异常，除非性能至关重要，或者除非您可能在不支持异常的环境（例如嵌入式平台）中运行。到目前为止，异常是调试的最佳选择，因为它们在发生时非常明显并且被忽略。此外，例外是自我记录的。它们有自己的类型名称，通常包含解释错误的消息。返回代码和 errno 需要单独的代码定义和某种带外方式来传达代码在任何给定上下文中的含义（例如手册页、注释）。

对于快速编码，返回代码可能更容易，因为它们不涉及潜在地定义您自己的异常类型，而且错误检查代码通常不像异常那样冗长。但当然，最大的风险是，默默地忽略错误返回码要容易得多，导致问题在发生后很久才被注意到，使调试和维护成为一场噩梦。

尽量避免使用 errno，因为它本身很容易出错。它是全局的，所以你永远不知道是谁在重置它，而且它绝对不是线程安全的。

编辑：我刚刚意识到你的意思是一个 errno 成员变量，而不是 C 风格的 errno。更好的是它不是全局的，但是您仍然需要额外的构造来使其线程安全（如果您的应用程序是多线程的），并且它保留了返回码的所有问题。

于 2008-11-21T01:14:11.293 回答
2

返回错误代码需要纪律，因为必须明确检查错误代码然后传递。我们编写了一个使用这种方法的大型基于 C 的系统，并且花了一些时间来消除所有“丢失”的错误。我们最终开发了一些技术来解决这个问题（例如将错误代码存储在线程全局位置并在顶层检查以查看返回的错误代码是否与保存的错误代码匹配）。

异常处理更容易快速编写代码，因为如果您正在编写代码并且不确定如何处理错误，您可以让它向上传播（假设您没有使用必须处理检查异常的 Java） . 它更适合调试，因为您可以获得异常发生位置的堆栈跟踪（并且因为您可以构建顶级异常处理程序来捕获应该在其他地方捕获的问题）。这对维护更好，因为如果你做对了，你会更快地收到问题通知。

但是，异常处理存在一些设计问题，如果弄错了，情况会更糟。简而言之，如果您正在编写不知道如何处理异常的代码，您应该让它向上传播。太多的编码人员捕获错误只是为了转换异常然后重新抛出它，导致意大利面条式异常代码有时会丢失有关问题原始原因的信息。这假设您在顶层（入口点）有异常处理程序。

于 2008-11-21T03:33:25.147 回答
0

就个人而言，在输出图形方面，我觉得无声失败很好。它只会让你的照片出错。

无论如何，图形错误非常容易发现。

于 2008-11-21T01:05:13.387 回答
0

就个人而言，如果它是纯“C”，我会在您的 Base 结构中添加一个 errno。如果这是 C++，我会抛出异常。

这取决于这些错误的“致命”程度。用户真的需要看到错误，还是为了其他开发者的熏陶？

为了可维护性，您需要清楚地记录可能发生的错误并包括错误处理的清晰示例。

于 2008-11-21T03:58:02.647 回答