C++ 奇怪的模式：所有函数/方法在C++；

在我最近的两个项目中，我看到了一条奇怪的准则，“所有方法/函数都应该使用一些常见的错误代码类型返回错误代码”。在这两个项目中，错误代码都是int-typedef

在C++中有什么好的理由吗？一些MISRA要求或类似的东西

我只看到缺点：

• 如果函数应该返回一个值，则通过参数引用完成。e、 g:
  字符串s； 错误\代码err=getString

• 功能的重要性并不明显。一切看起来都一样。错误列表包含数百个错误，从低级错误到某些特定于域的错误

您是否体验过这种编程风格？有好的论据来反对它还是支持它？

我已经看到了

内核编程就是这样，除非只有一个错误是可能的

---

这听起来不是一个好主意，但也不是一个坏主意。

对于团队来说，就返回错误的通用方法达成一致并不罕见，因为这有助于创建项目代码的通用“外观”，就像其他团队范围的编码约定一样。这可以帮助新的团队成员更快地了解整体情况，并使团队中其他人的代码的维护更加直观

< >我惊讶的是，C++项目是在错误后面而不是在异常之外统一起来的。这里讨论了使用异常与错误代码的利弊

---

我想支持错误代码处理的一个理由是，如果您使用的是C风格的API，它会引导您采用这种方法（cough…Win32…cough）。

我认为这是一种非常糟糕的风格，原因有几个

正如您所说，它强制您传递指针/引用以存储函数的实际结果

正如您所说，统一错误代码很难看，因为它试图统一来自各种域的各种错误

它创建了错误代码系统上所有程序模块的人工依赖关系，使得在其他程序中重用单个模块或模块的一小部分非常困难

此外，由于一些错误代码是特定于域的，它实际上在不相关的对象类型/模块之间引入了依赖关系，因为它们都依赖于一个组件，该组件依赖于它们所有可能的错误类型的联合

我的观点是，任何函数/方法如果有超过一小部分可管理的失败方式，要么过于复杂，要么考虑不周，可能两者兼而有之

如果您真的想返回错误代码，我会交换一些东西，将指向错误代码的指针作为参数传递给函数，并将实际结果作为返回值。然后，我将选择以下两种方法之一来实现错误代码：

简单的方法是：扔掉所有错误代码的抽象，简单地使用

int

和一些通用错误类

面向对象的方法：提供一个指向内部“错误对象”的指针，其中基类非常抽象，可以在所有组件之间共享，而不引入任何依赖关系，并且如果需要，每个组件定义自己的特定于组件的错误对象

---

如果使用C++，最好的方法可能是使用异常…

< p>这个习惯很常见，尤其是在C世界。

尽管我自己不使用它，而且我认为它弊大于利（在其他答案中更多地说明了这一点），但我确实发现了它的一个优点：一种向呼叫站点报告意外错误的一致方法。类似于errno变量，但更易于使用

例如，考虑一组函数：

int a();
std::string b();
double c();
std::list<long> d();

但这也会用一个额外的参数污染每个函数

---

不幸的是，在C语言中，如果您真的需要设计这样一个API来指示不同类型的故障，那么就没有太多的可能性以一种好的方式来实现。但是，在C++世界中，你可以使用异常。

< P>我已经看到了这样的论点：当链接到由另一个编译器编译的C++库，而不是用来编译二进制文件时，异常可能不起作用。虽然这种不起作用的说法可能完全正确，但实际上，即使是链接过程也不需要起作用（尽管每个人都可能遵守标准），因此，理论上，这种说法是无效的。然而，在实践中，可能（对不起，我在这里没有经验），名称冲突很少出现，对齐冲突很少出现，而且，除了例外，所有其他特定于实现的内容都得到了广泛的认可

我看到的第二个论点是运行时性能。虽然异常情况下的堆栈展开代价很高，但我还没有看到一个公平的基准，将异常与实际的返回代码检查量进行比较

在我的典型C++中，我使用混合。我使用较慢的异常处理我确实不希望经常发生的东西，或者测量为很少执行的代码路径，但返回更可能中断和可能频繁调用的东西的代码。

---

在紧循环中抛出异常，因为某些有趣的条件在每次迭代中都成立，这并不便宜（假设循环体可以处理它）。

看看（Windows）NT。所有系统调用和大多数其他函数都返回NTSTATUS值。很好，谢谢！在这两个项目中，不应使用例外情况：-（我猜这也是统一错误代码规则的原因-从来没有返回一个无效的值，通常您会用异常来表示。我认为这种方法不是最适合C++的，在这里您可以使用某种类型的类，并返回无效的值（例如通过提供BoOL ISVALUTE（）CONST；用一个类型的“魔法”值来表示失败是ihmo非常糟糕的风格。在Windows上，COM保证名称损坏和对齐

int x(bool* ok);