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

[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]

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

Читаемость - это сомнительно, скорее - наоборот: кода больше (лишнего причём), с чего бы читаемость-то тогда повысилась?
А вот монстроидальность такого кода неоспоримо выше!

exception - это не замена функции с параметром и последущими switch-case

Оно, насколько я помню, здорово отжирает стек. На МК да ещё с применением RTOS сиё - существенный минус.

[Forger]

Читаемость - это сомнительно, скорее - наоборот: кода больше (лишнего причём), с чего бы читаемость-то тогда повысилась?

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

А вот монстроидальность такого кода неоспоримо выше!

По ходу, вы не знаете о чем говорите. Либо мы ведем речь о разных в корне вещах.

Оно, насколько я помню, здорово отжирает стек. На МК да ещё с применением RTOS сиё - существенный минус.

Все там нормально работает и жрется стек не так криминально, особенно если камень выбрать правильно.
Конечно же на маленьких камнях exception ни к чему. Он нужен лишь в больших проектах. Впрочем, это я уже указал. Вообше, к чему все это?

В голом С - некая эмуляция exception - бред, реально бред упёртого сишника, который всеми правдами и неправдами ищет способ оправдать свой страх и не желание изучать нормальный инструментарий (в частности C++)

[AlexandrY]

В голом С - некая эмуляция exception - бред, реально бред упёртого сишника, который всеми правдами и неправдами ищет способ оправдать свой страх и не желание изучать нормальный инструментарий (в частности C++)

Справедливости ради там был бред упертого C++-ика
Он просто не знал как это правильно делается на C-и.
Кстати покажите ка свой код, а то не понятно на основании чего стоит прислушиваться к вашему мнению.