[one_eight_seven 3]

Это - не критическая ошибка, не фатальная. Т.е. "рабочая" ошибка. Поэтому и работать с ней нужно иначе (зависит от проекта, точнее от его ТЗ).

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

...контроллер квадрокоптера или робота, то какие там могут быть "рабочие ошибки"?

[AlexandrY 2]

А если шина не закорочена? А просто обрыв канала связи, например, радиоканала с пультом управления. И канал связи может восстановиться. Или датчик в сети теряет базу (orphaning). Это всё ошибки в работе системы. С точки зрения автомата - это рабочие ситуации, но они все начинаются с возврата ошибок. То же получение Nack - ситуация стандартная, но ошибочная, в том, смысле, что это ошибка работы системы.

Блин у меня пульсометр постоянно теряет связь с часами.

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

Т.е. понимаете, на Верхнем уровне не нужны никому такие ошибки и с ними никто не будет разбираться.

[haker_fox 60]

А с вашим понятием верха, создается ощущение как будто на верху вы только и ждете сбоев АЦП и там уже все готово к потере или искажению данных.

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

 

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

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

[one_eight_seven 3]

Блин у меня пульсометр постоянно теряет связь с часами.

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

Т.е. понимаете, на Верхнем уровне не нужны никому такие ошибки и с ними никто не будет разбираться.

У вас как, связь с реальностью не потеряна?

1. Вы купили некачественный товар, и вы имеете право требовать нормальной его работы.

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

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

Изменено 8 мая, 2018 пользователем one_eight_seven

[ViKo 1]

Это - уже критическая ошибка, ее можно избежать еще на этапе создания кода, добавив перед делением соотв. проверку.

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

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

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

[juvf 10]

вообще не использовать штатный механизма выделения памяти (malloc/free)

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

 

[Forger 17]

Товарищ...

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

 

[juvf 10]

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

 

ErCodeF1 myFunc1();

 

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

 

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

 

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

 

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

[Forger 17]

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

 

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

[ViKo 1]

...

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

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

 

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

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

[Forger 17]

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

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

Например, как в коде, где применяется примитивная функция, которая возвращает лишь два значения, понять, на какие возвращаемые значения реагировать, а на какие нет?

Каждый раз при создании или чтении кода лезть в ее описание?

 

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

[one_eight_seven 3]

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

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

[ViKo 1]

Я предполагаю 2 перечисления - универсальные коды завершения функций и ошибки аппаратные.

Первое перечисление я показал в начале темы. Это некие перестраховки от неправильно полученных аргументов.

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

Как на основе первых переходить ко вторым - частное дело в каждом случае.

[Forger 17]

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

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

[k155la3 26]

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

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