Это плохая идея смешивать коды bool и ret

Question

У меня есть несколько программ, которые интенсивно используют библиотеки с перечислением кодов ошибок.

Тип, где 0 (первое значение enum) является успехом, а 1 - неудачей. В некоторых случаях у меня есть свои собственные вспомогательные функции, которые возвращают bool, указывающий на ошибку, в других случаях я поднимаю количество ошибок. К сожалению, иногда я ошибочно принимаю одно за другое, и все терпит неудачу.

Что бы вы порекомендовали? Я пропускаю некоторые предупреждения на gcc, которые бы предупреждали в этих случаях?

P.S. кажется странным возвращать код ошибки, который совершенно не связан с моим кодом, хотя я думаю, что мог бы вернуть -1 или другое недопустимое значение.

Answer 1

Это плохая идея? Нет, вы должны делать то, что имеет смысл, а не следовать некоторому абстрактному правилу (подобное которому почти никогда не учитывает все ситуации, с которыми вы все равно столкнетесь).

Один из способов избежать неприятностей - убедиться, что все функции, возвращающие логические значения, читаются так, как на английском, например: isEmpty(), userFlaggedExit() или hasContent(). Это отличается от моих обычных конструкций глагола, таких как updateTables(), deleteAccount() или crashProgram().

Для функции, которая возвращает логическое значение, указывающее на успех или неудачу функции, которая обычно следует этой конструкции глагола-существительного, я склонен использовать что-то вроде deleteAccountWorked() или successfulTableUpdate().

Во всех этих случаях с логическим возвратом я могу создать легко читаемое if утверждение:

if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...

и т. Д.

Для функций, не возвращающих логические значения, я все еще придерживаюсь соглашения, что 0 в порядке, а все остальные значения являются ошибками какого-либо рода. Использование интеллектуальных имен функций обычно означает, что очевидно, какие именно.

---

Но имейте в виду, это мое решение. Это может или не может работать для других людей.

Answer 2

Я бы не сказал, что это плохая практика.

Нет необходимости создавать тонны enum -s, если вам просто нужно вернуть true / false, и у вас нет других вариантов (и true и falseдостаточно объяснительно).

Кроме того, если ваши функции называются OK, у вас будет меньше «ошибок»

Например - IsBlaBla - ожидает возврата true.Если у вас [Do|On]Reload, перезагрузка может произойти по многим причинам, поэтому можно ожидать enum.То же самое для IsConnected и Connect и т. Д.

Answer 3

Если стандартизировать схему с нулевой ошибкой ==, вы можете смешивать и сопоставлять как enum, так и bool, если вы строите свои тесты следующим образом:

err = some_func (); if! err ...

Так как первое перечисление оценивается как ноль, а также случай успеха, то он идеально совпадает с возвратом ошибки bool.

Однако в общем случае лучше возвращать int (или enum), поскольку это позволяет расширять возвращаемые коды ошибок без изменения вызывающего кода.

Answer 4

В частях приложения, которыми вы управляете, и в частях, которые составляют ваш внешний API, я бы сказал, , выберите один тип обработки ошибок и придерживайтесь его .Какой тип менее важен, но будьте последовательны.В противном случае люди, работающие над вашим кодом, не будут знать, чего ожидать, и даже вы сами почесаете голову, когда вернетесь к коду через год или около того;)

Answer 5

ИМХО функция именования помогает здесь.

например. для функций, которые возвращают логическое значение is_foo_bar (...), или для функций, которые возвращают успех или код ошибки, do_foo_bar (...).