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

[ViKo]

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

[haker_fox]

не получиться универсального енума, глупости это. ИМХО. Тем более 8 или всего 4 значения. У каждой функции своя задача и свои возвращаемые значения.
мой черновик функции включения вращения антенны

Как вы передаёте код ошибки при вложенном вызове функций? Т.е. снизу на верх?

Слышали такое слово "говнокод"?

Ну конечно слышал, как и множество других мерзких слов. Тут вопрос в другом, позволить себе использовать это по отношению к другим, или нет?

Чужой код - всегда гавно. Каким бы он ни был.

Я понял, что вы имеете в виду Мне такие намёки тоже делали. Не прямыми словами. Когда я парировал, что это мой собственный стиль написания кода, человек, оскорбивший моё творчество, сватил жёсткий "батхёрт", и начал меня учить, что стили в коде это совершенно другое. В общем его задача была обругать, а не понять. И ему мои объяснения (хотя он мне и не начальник) были совершенно не нужны. К слову, его код постоянно подвергается справедливой (на мой взгляд) критике. Не ругане, а критике. Поэтому делаю вывод (не только по этому случаю), тот кто умеет делать дело, других ругать не станет. Максимум - аккуратно посоветует, как можно по-другому. Ну, а возомнивший себя профессионалом, будет изрыгать огонь налево и направо, при этом тащась от творений себе подобных

[juvf]

Как вы передаёте код ошибки при вложенном вызове функций? Т.е. снизу на верх?

Чаще я ошибки обрабатываю на месте и мне не нужно их передавать выше. Если нужно выше передать, то делаю общий енум кодов ошибок для отдельного куста.

[haker_fox]

Чаще я ошибки обрабатываю на месте и мне не нужно их передавать выше. Если нужно выше передать, то делаю общий енум кодов ошибок для отдельного куста.

Понятно! У вас тоже общий энум всё-таки не исключён
У меня была задача передавать коды ошибок "на верх" не только через иерархию функцию, но и устройств. Т.е., например, "железяка1"-"железяка2"-"комп".

[AlexandrY]

Понятно! У вас тоже общий энум всё-таки не исключён
У меня была задача передавать коды ошибок "на верх" не только через иерархию функцию, но и устройств. Т.е., например, "железяка1"-"железяка2"-"комп".

Зачем вам передавать вверх?
Это как минимум выставляет дополнительные требования ко всем программным интерфейсам снизу вверх.
Сковывает рефакторинг. Увеличивает объем кодирования. Рассеивает точку внимания. Вызывает новые зависимости.
Т.е. в чем корневая причина?
Вас заставляют так делать, делаете библиотеки, корпоративный стандарт, используете IDE с ограниченными возможностями рефакторинга или что?

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

[Forger]

... везде где можно использую глобальные переменные ...

Это многое объясняет

Кстати, в данное время я решил выдавать результаты POST проверок бипами, пищалкой.

Наверно, есть смысл разделять ошибки на критические (аналог исключений в C++) и обычные, "рабочие".
Критические это те, которые не дают нормально работать приложению, т.е. аварийные.
Бипами, имхо, стоит афишировать критические ошибки (как на многих мат. платах компов).

А обычные ошибки лучше всего обрабатывать в коде именно в том месте, где производится вызов некой функции, которая возвращает ошибку.
В идеале нужно обрабатывать ВСЕ возможные ошибки, которые может возвратить некая функция. Т.е. предусмотреть поведение кода на ЛЮБУЮ ситуацию.
А передавать эту ошибку дальше не есть хорошо - это называется "скинуть ответственность", что всегда плохо заканчивается, зачастую создавая настолько редкие баги, что потом их ищут неделями.
Самый простой случай, когда код ошибки - возврат true/false, его очень просто обрабатывать (if ... else), читать и понимать такой код тоже очень просто.
Поэтому я тоже не понимаю таких вещей как "глобальные ошибки", универсальный набор ошибок и т. п. Сопровождать и отлаживать такой код - крайне неблагодарное занятие.
Как тут уже говорили комрады: универсальные решения - зло. Каждый кусок кода (модуль) должен делать именно то, что должен, и не более того.

Если же по необходимости используется сторонняя библиотека, то передавать возвращаемые ею ошибки дальше по коду - не есть хорошо. В последствии это принесет немало геморроя (см. выше).
Поэтому я лично предпочитаю "изолировать" внешние библиотеки от основного кода т. н. обертками (wrapper), в которых скрыта вся "черновая" работа по разгребанию результатов работы "неуклюже" написанной библиотеки.
А сам функционал (интерфейс) этой "обертки" урезать до минимума, оставляя самое необходимое и реальное важное.
При использовании исключений C++ можно "кидать" некоторые действительно важные исключения, но их обязательно нужно документировать, чтобы потом в коде правильно их "отлавливать".
Так же как аналог подобных критических исключений (как тут уже говорили выше) отлично годятся SVC вызовы. Их можно использовать на asm/c/c++.

[AlexandrY]

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

Странная идея - добавить еще кода чтобы сделать код более понятным.
На самом деле эта изоляция - это наказание любителям плюсов вокруг которых все либы написаны на C.
Они вынуждены писать изоляцию чтобы скрестить ежа с ужом.

[Forger]

Странная идея - добавить еще кода чтобы сделать код более понятным.

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

На самом деле эта изоляция - это наказание любителям плюсов вокруг которых все либы написаны на C.

Плюсы тут ни при чем. Изолировать чужой говнокод можно даже на асм-е.
Можно даже изолировать чужой C++ говнокод на голом С, если в этом, конечно, есть особая нужда.
Однако, на плюсах (или другом аналогичном языке) грамотно проектировать проект намного проще и поэтому значительно удобнее в использовании и дальнейшем сопровождении кода.
Это вам скажет любой профи, который после ручной пилы освоил электро-лобзик, бензопилу и т.п. : ручную пилу он будет использовать лишь для мелких поделок и допилов.

Они вынуждены писать изоляцию чтобы скрестить ежа с ужом.

В который раз прихожу к выводу, что вы не достаточно знакомы с предметом этого разговора и поэтому судите весьма поверхностно. Увы
Но это вполне нормально - чего-то не знать или не уметь. Ведь это поправимо: нынче очень много полезной развивающей литературы, было бы желание

[AlexandrY]

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

За употребление слова "говнокод" я б вас забанил.
На самом деле так называют код в котором не могут разобраться, не знают контекст в котором он писался и для кого писался.
Таким образом перенося свою эмоцию на несчастный код.
А потом еще и изолируетесь от этого кода.
Вам похоже тяжело дается чужой код.
Дам вам совет. Не воюйте с кодом, а делайте его своим.
Начните с перехода на чистый С-и с урезанными синтаксисом, лучше даже MISRA-С. Пишите на языке на котором написана основная масса вашего кода.
Освойте рефакторинг, и увидите как у вас пропадут отрицательные эмоции к коду.