Способы обработки ошибочных ситуаций

Добрый вечер!!

Расскажите ваше мнение на тему обработки ошибок, как лучше реализовать?

Заранее благодарю вас за ответы!!

0

с помощью исключений

1

А можно поподробнее) Или может книгу посоветуете?

0

в случае обнаружения ошибки исключения позволяют прервать поток выполнения программы и передать упралвение обработчику ошибок.
исключения описаны в любом учебнике по C++. например Бьерн Страуструп - Язык программирования C++.
еще очень хорошая книга - Брюс Эккель, Чак Эллисон - Философия C++

1

Сообщение от krazyd Расскажите ваше мнение на тему обработки ошибок, как лучше реализовать?

1) Обрабатывать все возможные ошибки. Все. Повторю еще раз - все. Да, все.
Многие почему-то этого не делают. Если некая функция может вернуть false, вы
обязаны проверить это. Если в программе вызывается три сотни разных функций,
каждая из которых может завершиться ошибкой, вы обязаны написать код проверки
возвращаемого значения к каждой из них. Если метод некоего класса может выбрасывать
исключение, вы не должны помещать код его вызова в try/catch с пустым блоком catch -
это худшее, что можно придумать. Если некая операция или последовательность операций
завершается неудачей, то самое плохое, что можно в этом случае сделать - тихо
замолчать факт ошибки или, что еще хуже, попытаться выполнить ту же операцию, но
каким-то другим способом.

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

Суть качественной обработки ошибок - максимально резкая реакция на их возникновение,
вместе со сбором максимально полной информации о контексте. Разумеется, есть ошибки
логические, которые являются ожидаемыми, например, невозможность сохранить данные в файл
из-за отсутствия прав на запись. В этом случае, очевидно, следует показать пользователю
какое-то осмысленное, "человеческое" сообщение и продолжить работу адекватным и наиболее
ожидаемым для него способом. Все остальное, что попадает в класс "unexpected", "overflow",
"no memory", деление на ноль и т.п., должно обрабатываться соответствующим образом.

2) Принцип в пункте 1 распостраняется на ключевые аспекты архитектуры приложения.
Если есть некий API, он должен быть спроектирован так, чтобы его можно было использовать
лишь одним, и никаким другим способом. И при попытке хоть что-то сделать не так должна
возвращаться ошибка. Если некий клиентский код, работая с нашим протоколом обмена данными,
посылает их не в том порядке, не с теми заголовками, с неверной длиной и т.п., то ни в
коем случае не следует пытаться "угадать" намерения клиента. Снова лучшая стратегия здесь -
сразу прервать обработку и вернуть соответствующий код ошибки. Как привередливая и
чрезмерно внимательная к деталям тетка. Вообще, чем уже "коридор" выполнения кода, тем
меньше возможностей где-то накосячить и сойти пути, который был намечен разработчиком.
Это один из ключевых принципов.

3) Не следует пытаться "восстановиться" после какой-то критической ошибки. Самое лучшее и
простое - дать программе просто упасть, сообщив пользователю о том, что произошло, ну возможно
еще снять крэш-дамп и создать логи. Не следует применять здесь какие-то "умные" стратегии,
они все равно будут нелепы.

4) Слой обработки ошибок должен быть четко отделен от слоя бизнес-логики приложения.
Иначе вы рискуете получить спагетти-код, нашпигованный if-ами через каждые три строчки.
Такой код очень трудно понимать, т.к. "лес" не видно за "деревьями". Исключения обычно
помогают достичь этой цели, к тому же их, в отличие от true/false и кодов возврата,
нельзя проигнорировать. То есть, где-то на низком уровне мы пишем реализацию, со всеми
свойственными ей заморочками, детализацией, проверкой ошибок и т.п., а сверху должен
быть простой, очевидный, компактный и самодокументированный код, чтобы одного взгляда
на который для любого смертного, даже не знакомого с программированием, хватило бы
для понимания того, что этот код делает.

5) "Исключения vs коды возврата" - руководствуемся соображениями пункта 4 (исключения
позволяют этого достигнуть), а также тем, что в объект исключения можно запихнуть любое
количество полезной информации. Но при этом учитываем перфоманс (коды быстрее) и вопросы
переносимости (выброс исключения даже за пределы модуля уже может привести к проблемам, а
из-за отсутствия ABI они не совместимы между компиляторами и, иногда, между разными
версиями одного и того же компилятора).

6) Ассерты, проверки инвариантов и тому подобное, должны быть расставлены на каждом шагу.
Это помогает отслеживать возникновение ошибок при внесении изменений в код, что очень важно.
Хороший ассерт, который вдруг выстрелил, сразу дает понять, что именно произошло и почему.

12

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

Убежденный, привет. Вот смотрите, допустим обернули мы код (на низком уровне, в функции main например) в блок try. К примеру в этом коде есть несколько вызовов new. Как мы узнаем какой из вызовов сфэйлил? Из-за данной проблемы приходится писать спагетти-код:
Как быть?

0

Можно заменить new на какую-нибудь функцию/макрос, которая будет делать
try/catch и формировать всю нужную информацию в случае возникновения исключения.

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

1

Ошибки бывают разные.
И я всё больше склоняюсь к тому, чтобы использовать исключения только для обрушения программы.
Во всех остальных случаях, когда программа должна достичь некоторого определённого результата, использовать или вычисления в контексте, если средства языка позволяют, или коды ошибок, если важна производительность либо язык не позволяет. Исключения, на мой взгляд, особенно неудачны, когда речь идёт о "graceful degradation".

0

Сообщение от mporro или коды ошибок, если важна производительность

Здесь Вас могут оспорить, конечно,
в зависимости от реализации самого механизма исключений
и реализации других способов обработки ошибок.
По теме: https://habrahabr.ru/post/208006/
Но, имхо, пихать всюду исключения тоже не есть хорошо.
Всё-таки, большую часть проблем можно решить "на месте",
без обращения к "вышеисполняющемуся" коду.

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

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

0

Сообщение от Croessmah про них нельзя просто так забыть

Про вычисления в контексте тоже нельзя забыть.
Да и про коды ошибок... Если код правильно организован с логической точки зрения.

А намеренно пропустить можно и исключения, как Вы сами упомянули.

0

Сообщение от mporro А намеренно пропустить можно и исключения, как Вы сами упомянули.

Вот как раз в последнем проекте так и сделал.
Функция не моя, кидает исключения, зараза, при ошибке.
Но мне её результат не так и важен, можно его просто игнорировать...
пришлось запихнуть в try и пустой catch оставить
(запись в лог всё-таки сделал, правда, пока еще ни разу её там не видел)

0

Сообщение от Croessmah Всё-таки, большую часть проблем можно решить "на месте"

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

0

Можно замутить монадический стиль обработки ошибок (на основе std::optional) так, как это делается в Haskell, Rust и тд и тп.

Сообщение от Croessmah Одно из хороший свойств исключений - про них нельзя просто так забыть.

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

0

Сообщение от ct0r Более того, они позволяют не забыть про обработку еще на этапе компиляции

Угу, а если забыли, то узнаете об этом... эммм... не пойми как.

P.S. Не будем разводить холивар, все делают так, как могут/хотят/требуется.

0

Сообщение от Croessmah Угу, а если забыли, то узнаете об этом... эммм... не пойми как.

Легко узнаю. Через ворнинги от компилятора. Привет C++17 и атрибут nodiscard!

0

Сообщение от ct0r Привет C++17 и атрибут nodiscard!

Еще не приняли же C++17.
Ну и что делать без него?

В общем, обрабатывать ошибки будем так, как велит ситуация

0

Croessmah, ждать поддержки компиляторами конечно же! А так уже все определились с тем, что в С++17 будет, а что нет.
nodiscard будет в ближайших релизах, gcc и clang уже имеют его в мастере.
С точки зрения ошибок может быть еще удобна фича structured bindings, но ее еще не делали.

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

1

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

У меня сейчас выработался такой подход. В случае возврата ошибки из функции/метода делаю запись в лог и роняю прогу. Если по логу разобраться не удалось, изучаю дамп. В функциях/методах которые бросают исключение (new, wcscpy_s etc), в случае ошибки сразу переходим к изучению дампа. Т.е. try/catch я вообще не юзаю. Ну и ничего вроде, привык уже так. Не знаю, может подход нубский, я новичок в c++.

0

Сообщение от Убежденный 3) Не следует пытаться "восстановиться" после какой-то критической ошибки. Самое лучшее и простое - дать программе просто упасть, сообщив пользователю о том, что произошло, ну возможно еще снять крэш-дамп и создать логи. Не следует применять здесь какие-то "умные" стратегии, они все равно будут нелепы.

у нас самолет пассажирский.
отказал двигатель.

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

так мы будем восстанавливаться после паники,
или будем ронять самолет со всеми людьми на борту?

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

приведите пример:
как компилятор вежливо напомнит про обработку.

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

с наглой мордой - это когда ошибка маскируется.

но есть ещё третий вариант:
"строгие гарантии",
с возможностью полного восстановления после паники
(гарантии ликвидации последствий аварии)

1

hoggy, я вроде писал уже:
либо просто атрибут nodiscard - тогда ворнинг
либо явный монадический тип в возвращаемом значении (std::optional) - тогда ошибка компиляции

0