我有一些程序大量使用带有错误代码枚举的库。
0（枚举的第一个值）是成功而 1 是失败的那种。在某些情况下，我有自己的帮助函数，它们返回指示错误的 bool，在其他情况下，我会冒泡错误枚举。不幸的是，有时我把一个误认为另一个，事情就失败了。
你会推荐什么？我是否错过了一些关于 gcc 的警告，这些警告会在这些情况下发出警告？
PS 返回一个与我的代码完全无关的错误代码感觉很奇怪，尽管我想我可以返回 -1 或其他一些无效值。
5 回答
4
这是个坏主意吗？不，你应该做有意义的事，而不是遵循一些抽象的规则（这些规则几乎永远不会满足你将遇到的所有情况）。
我避免麻烦的一种方法是确保所有返回布尔值的函数读起来都像正确的英语，例子是isEmpty(),userFlaggedExit()或hasContent(). 这与我的正常动词-名词结构不同，如updateTables(),deleteAccount()或crashProgram()。
对于返回布尔值的函数，该布尔值指示通常遵循动词-名词结构的函数的成功或失败，我倾向于使用类似deleteAccountWorked()or的东西successfulTableUpdate()。
在所有这些返回布尔值的情况下，我可以构造一个易于阅读的if语句：
if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...
等等。
对于非布尔返回函数，我仍然遵循约定，即 0 是可以的，所有其他值都是某种错误。使用智能函数名称通常意味着哪个是哪个是显而易见的。
但请记住，这是我的解决方案。它可能适用于其他人，也可能不适用。
于 2011-06-13T08:03:26.450 回答
1
在您控制的应用程序部分以及构成您的外部 API 的部分中，选择一种类型的错误处理并坚持使用它。哪种类型不太重要，但要保持一致。否则，在你的代码上工作的人将不知道会发生什么，甚至当你在一年左右回到代码时，甚至你自己也会挠头；）
于 2011-06-13T07:47:51.213 回答
1
如果在零 == 错误方案上进行标准化，则可以混合和匹配 enum 和 bool 如果您像这样构建测试：
错误 = some_func(); 如果！错误...
由于第一个枚举的计算结果为零，而且成功案例也与 bool 错误返回完美匹配。
但是，通常最好返回一个 int（或 enum），因为这允许在不修改调用代码的情况下扩展返回的错误代码。
于 2011-06-13T07:50:23.793 回答
1
我不会说，这是一个不好的做法。
enum如果您只需要返回true/false并且没有其他选项（并且true足够false解释） ，则无需创建大量-s。
此外，如果你的函数命名为 OK，你的“错误”就会更少
例如IsBlaBla——期望返回true。如果您有[Do|On]Reload，重新加载可能会由于多种原因而失败，因此enum可以预料。IsConnected和Connect等也是如此。
于 2011-06-13T07:57:00.117 回答
0
恕我直言，函数命名在这里有所帮助。
例如，对于返回布尔值的函数，is_foo_bar(...)，或者对于返回成功或错误代码的函数，do_foo_bar(...)。
于 2011-06-13T07:51:17.160 回答