Коды завершения функции Опции

[ViKo]

Иногда приходится придумывать некие коды, информирующие о той или иной ошибке при выходе из функции. К EXIT_SUCCESS и EXIT_FAILURE добавляются дополнительные. Не задавались ли вы целью привести коды в систему, чтобы пользоваться во всех случаях? Если да, поделитесь, пожалуйста идеями.

[arhiv6]

А кто-нибудь использует для обработки ошибок CException или что-нибудь подобное? Вот ещё о нём: Обработка исключений на языке C.

[Forger]

А кто-нибудь использует для обработки ошибок CException или что-нибудь подобное?

Поделюсь своим небольшим опытом ))

В толстых проектах - обязательно С++ и exсeption.
В маленьких и средних тоже С++, но без тяжелых exсeption (отъедает много места у маленьких камней).

Стараюсь всегда избегать функций (в C++ методов), которые помимо основной своей задачи еще и возвращают код ошибки.
Максимум - такая функция возвращает bool. Это дает возможность дать фунции осмысленное имя в соотв. с построением языка носителя - английского.
Это капитально улучшает читаемость кода, т.к. не нужно после возврата из такой функции проводить анализ возвращаемого кода ошибки с монстроподобным switch-case.

Например, нужно дождаться какого-то события (освобождения мьютекса), использую такую конструкцию:

Код

if (someSemaphore.isWaitingDone(100ms))
{
.....
}else...

Если нужно ждать бесконечно, то просто:

Код

someSemaphore.wait();

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

Чем проще входная и выходная часть функции, тем проще ее применять.
Кстати, насчет входной части: если в функцию передается более двух параметров, то такая функция требует перестроения.
В сложных случаях в функцию лучше передавать указатель (а в С++ ссылку) на экземпляр структуры, которую нужно заранее создать и вписать в нее нужные параметры.
Читаемость такого кода значительно выше, чем функция, в которую суют вагон разношерстных параметров и еще эта функция возвращает какой-то код ошибки.
В крайнем случае лучше сделать отдельную функцию для возврата кода ошибки в стиле getLastError, но это анахронический костыль, который лишь немного улучшает ситуацию.
Обычно, если функция может возвращать кучу разных ошибок, то это - неудачная функция и поэтому требует перепроектирования код модуля, где она применяется.
В случаях вынужденного использования чужого кода "as is", такие страшные функции лучше изолировать т. н. "обертками" (в С++ для этого отлично годится понятие класс).

Короче, сложные запутанные куски кода прячьте в простые и однозначные модули, узлы, классы и т. п.
Давайте сущностям (функции, объекты) полные и однозначные имена. Это навык в дальнейшем очень сильно пригодится.


Вы правильном мыслите в сторону exeption, но на голом C это - сто шагов назад, ближе к эпохе неолита )))
Правильный путь - изучать С++, а точнее грамотное проектирование на нем.
Сейчас остается все меньше и меньше кода на голом С, он явно умирает, равно как и умер в свое время ASM в чистом виде (я не говорю про небольшие вставки на ASM, где это жизненно необходимо в некоторых случаях).


зы. недавно в своем "любимом" Keil я перешел на С++11/14 (компилятор v6.10), кстати код получается меньше и быстрее
Можно сказать "пришлось" это сделать, т. к. С++03 (компилятор v5) сильно ограничивает применение чужого кода, который в большинстве своем требует как минимум C++11.

[jcxz]

Это капитально улучшает читаемость кода, т.к. не нужно после возврата из такой функции проводить анализ возвращаемого кода ошибки с монстроподобным switch-case.

Ну да - заменяя на монстроподобный механизм exception.

Сейчас остается все меньше и меньше кода на голом С, он явно умирает, равно как и умер в свое время ASM в чистом виде

Сейчас всё меньше и меньше народу пишет на си, всё больше быдлокодят на абдурине. Следуя Вашей логике - так и следует делать.
И все остальные утверждения - по меньшей мере спорны, если не полностью ложны....

[Forger]

Ну да - заменяя на монстроподобный механизм exception.

exception - это не замена функции с параметром и последущими switch-case (если функции вложенные, то вообще полный швах - кода много, да толку мало)
это вообще разные вещи и применять их следует в разных ситуациях
Есть неплохие статьи на эту тему: https://habr.com/post/264417/

Я лично использую exception только для аварийных (исключительных) ситуаций, а разбор ошибок реализую несколько иначе (см. предыдущий пост).
Причина этому у меня лично очень простая - не очень хорошая память и лень:
не могу в голове удерживать десятки невнятных функций с их кучей параметров и лень рыться в мануалах каждый раз как их использовать ))

всё больше быдлокодят на абдурине. Следуя Вашей логике - так и следует делать.

Я смотрю, ардуинщики для вас - больная тема А быдлокодеры - это вообще отдельная каста "программеров". Приходится с ними часто работать? Тогда сочувствую (((
Кстати, редкий ардуинщик понимает, что имеет дело с вполне полноценным С++ компилятором под AVR и потому строчит он по сути на голом С.