Товарищ, если вы внимательнее пересмотрите посты дискусии, вы увидите, что чуть выше я эти же ситуации привёл именно в качестве примера "рабочих ошибок", как ответ на вопрос

Блин у меня пульсометр постоянно теряет связь с часами.
Если я пожалуюсь на это производителю и скажу что это ошибка там чья-то, они будут смеяться мне в лицо.
Т.е. понимаете, на Верхнем уровне не нужны никому такие ошибки и с ними никто не будет разбираться.

Зато, если произойдёт сбой, то я буду знать, где искать.


Ну у каждого свой подход)

У вас как, связь с реальностью не потеряна?
1. Вы купили некачественный товар, и вы имеете право требовать нормальной его работы.
2. Обрыв датчика нужно видеть на верхнем уровне. Потерю связи с беспилотником нужно видеть на пульте. Но обе эти вещи обработаются локально, поскольку они видны на обоих концах.
3. Возвращаясь к теме дискуссии, если беспилотник потерял связь с пультом, то функция, которая ждёт Ack (условно говоря), не должна возвращать OK, она должна вернуть либо FAIL, либо NO_ACK, либо NACK (в зависимости от того, что произошло), и это коды ошибочного завершения работы функции. Что с этим будет дальше - не дело функции, она вообще не должна "знать" что там дальше. Абстракции - это же основное, что должен знать разработчик.

Сообщение отредактировал one_eight_seven - May 8 2018, 06:15

Положим, так и делается. Америку не открыли.

Это мне решать.

временные массивы обычно на стеке выделяются, типа int tempArray[1024]; конечно если стека не фватит - то фолаут! малоком можно избежать фалаута, но делать времянки в куче - мовитон. Как решение alloca - динамическое выделение памяти на стеке. Тут наверно будет это полезно, и организовать возврат ошибки вместо фалаута.

Дискуссия постепенно ведет к холивару

ещё по теме..... вот функция объявлена как

ErCodeF1 myFunc1();

ErCodeF1 - тип енум из 3-х кодов. Я глянул этот енум и я понимаю, что может вернуть myFunc1(). Во первых, мне не нужно писать документацию на возвращаемые значения, всё понятно по именам в енуме, в крайнем случае комент на код ошибки в енуме. Во вторых я могу сделать обработку для каждого кода ошибок. Их всего 3 (один из них будет NO_ERROR, т.е. даже 2 кода ошибки.)

Тоже самое могу сказать про ErCodeF2 myFunc2();, ErCodeF4 myFunc4();, ErCodeF3 myFunc3() и т.д. у каждой функции только необходимое кол-во кодов ошибок.

Теперь делаем общий енум ошибок ErCode (или адский, как у AlexandrY), вызываем функцию ErCode yourFunc1(); какие возможные коды она вернёт? На какие коды ошибок писать обработчик? Нужно лезть в какие-то мануалы, читать описания....

неудобно. имхо.

Это еще мягко сказано

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

А как тогда отделить "мух от котлет": какие ошибки функция может возвращать, а какие нет?
Например, как в коде, где применяется примитивная функция, которая возвращает лишь два значения, понять, на какие возвращаемые значения реагировать, а на какие нет?
Каждый раз при создании или чтении кода лезть в ее описание?

Все наверняка сталкивались с книгами, перегруженными поясняющими комментариями внизу страницы. Хорошо, если они внизу страницы, а если все собраны в одну кучу в конце книги?

Обратная аналогия. А если глоссарий будет не в конце книги, а в конце каждого раздела?

Я предполагаю 2 перечисления - универсальные коды завершения функций и ошибки аппаратные.
Первое перечисление я показал в начале темы. Это некие перестраховки от неправильно полученных аргументов.
А второе - это то, что будет требовать выдачи пользователю или регулировщику. Например, "неисправен контроллер ЖКИ". Их еще "выпискивать" буду при включении. С этими ошибками прибор работать не может.
Как на основе первых переходить ко вторым - частное дело в каждом случае.

© "Хрен редьки не слаще"

Реализация активно используется в Windows, один параметр используется как код события (коих множество типов), второй - указатель на евойные даннные (типо-зависимые).