Правильный подход для обработки ошибок в C++

Question

Одним из них является использование исключений C++: try catch blocks. Но освобождение динамической памяти будет проблемой при возникновении исключения.

Во-вторых, использовать стиль C: ERRNO переменная

В-третьих, это просто возвращает -1 при ошибке и 0 в случае успеха :)

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

Answer 1

Но освобождение динамической памяти будет проблемой при возникновении исключения.

Нет, это не так. std::vector<int> v(100); Готово.

Концепция здесь называется областью управления ресурсами (SBRM), также известной гораздо более распространенным (и неудобным) именем «Инициализация ресурсов» (RAII). В принципе, все ресурсы содержатся в некотором объекте, который очистит ресурс в деструкторе (который всегда гарантируется для автоматически назначенного объекта). Таким образом, независимо от того, существует ли функция нормально или через исключение, деструктор запускается и ваш ресурс очищается.

Никогда не делайте выделение, где вам необходимо бесплатно его освободить, используйте контейнеры и интеллектуальные указатели.

Answer 2

Во-вторых, использовать стиль C: ERRNO переменная

В-третьих, это просто возвращает -1 при ошибке и 0 в случае успеха :)

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

Таким образом, они не имеют преимуществ перед исключениями C++ (согласно вам).

Answer 3

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

Answer 4

Посмотрите на этот комментарий Herb Sutter на try catch for C++ GOTW. И пройти весь его набор статей. У него есть много сказать, когда и как проверить и спасти себя от условий ошибок и как справиться с ними наилучшим образом.

Answer 5

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

Исключения - хороший инструмент, но should be used conservatively: зарезервируйте их для «исключительных случаев», не используйте их для управления потоком вашей программы.

Например, не используйте исключения для проверки правильности ввода данных пользователя. (В таком случае верните код ошибки.)

Answer 6

Но освобождение динамической памяти будет проблемой при возникновении исключения.

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

Answer 7

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

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

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

Answer 8

Один из них заключается в использовании исключений C++: try catch blocks. Но освобождение динамической памяти будет проблемой при возникновении исключения .

@see RAII.

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

Красота обработки исключений, если вы делаете это правильно (опять же, @see RAII), заключается в том, что она избегает необходимости выметать код обработки ошибок в вашей системе.

Рассмотрим случай, когда функция A вызывает функцию B, которая вызывает C, затем D и т. Д., Вплоть до «Z». Z - единственная функция, которая может бросать, и A является единственной, кто заинтересован в восстановлении от ошибки (A - это точка входа для операции высокого уровня, например, загрузка изображения). Если вы придерживаетесь RAII, который будет полезен для обработки исключений, тогда вам нужно будет поместить строку кода в Z, чтобы выбросить исключение и немного блока try/catch в A, чтобы поймать исключение и, скажем, отображение сообщение об ошибке пользователю.

К сожалению, многие люди не придерживаются RAII так строго, как должны на практике, поэтому в большом количестве кода реального мира есть больше блоков try/catch, чем это необходимо, чтобы справиться с ручной очисткой ресурсов (что shouldn ' t должен быть ручным). Тем не менее, это идеал, который вы должны стремиться достичь в своем коде, и это более практично, если это проект среднего размера. Аналогично, в реальных сценариях люди часто игнорируют коды ошибок, возвращаемые функциями. если вы собираетесь добавить лишнюю милю в пользу надежности, вы можете начать с RAII, потому что это поможет вашему приложению независимо от того, используете ли вы обработку исключений или обработку кода ошибки.

Существует предостережение: вы не должны бросать исключения через границы модулей.Если вы это сделаете, вы должны рассмотреть гибрид между кодами ошибок (как при возврате кодов ошибок, не используя глобальный статус ошибки, как errno) и исключения.

Стоит отметить, что если вы используете оператор нового в коде без указания nothrow везде, например:

int* p = new int(123); // can throw std::bad_alloc 
int* p = new(std::nothrow) int(123); // returns a null pointer on failure 

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