[РЕШЕНО] Обработка ошибок без исключений и с помощью исключений

[Igors]

Я же хочу проанализировать разные подходы и выбрать один.

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

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

И еще: анализировать различные подходы легко и приятно. Но всегда есть противные мелочи, напр

Вы работаете с Qt и вероятно будете использовать QDataStream. Как заставить его выбрасывать исключения?

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

[8Observer8]

Я боюсь, что если буду везде использовать подход с showError(), то будет таже самая ситуация. Опять же не вижу конкретных проблем в примере с исключениями при работе с файлами. Чем подход с showError() лучше чем подход с классами исключений?

[Old]

Я вам специально цитату привёл В Windows это является исключением

Это не является исключением C++, хотя SEH и очень похож (__try, __except).

Скот Мейерс в своей книге "Наиболее эффективное использование С++" утверждает, что повсеместное использование исключений в программе приведёт к снижению скорости выполнения программы на 5-10%.

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

но это не имеет преимуществ перед другими решениями и не улучшает структуру и читаемость программы.

Да ну ладно. Этот пример с выходом из глубокой функции с возвратом результата хорошо это подтверждает.

PS собственно и получается интересная деталь - при использовании "кода с исключениями" всегда может быть ситуация, что исключений будет типов 10-15. При использовании библиотек может доходить и до 20-30. И для обработки всех событий вам придётся писать 30 блоков обработки. А у 20 из 30 исключений внутри будут разные структуры, и это становится невыносимым

Скажите честно, вы никогда не писали программ с исключениями.
Все что вы написали выше, мягко говоря, ерунда.

[Old]

Я боюсь, что если буду везде использовать подход с showError(), то будет таже самая ситуация.

Конечно. Ненужно зацикливаться.

Опять же не вижу конкретных проблем в примере с исключениями при работе с файлами.

Потому, что их нет.

Чем подход с showError() лучше чем подход с классами исключений?

Ничем, а часто он хуже.

[Bepec]

но это не имеет преимуществ перед другими решениями и не улучшает структуру и читаемость программы.

Да ну ладно. Этот пример с выходом из глубокой функции с возвратом результата хорошо это подтверждает.

Скажите честно, вы никогда не писали программ с исключениями.
Все что вы написали выше, мягко говоря, ерунда.

1) Читайте внимательнее. Там написано что обработка не исключительных ситуаций при помощи исключений и далее текст цитаты. Т.е. применение исключений везде даёт худший результат,чем совмещение разных подходов.

2) писал. Qt/C++/Boost/*** (секретная разработка )/OPC. Примерно 8 блоков для обработки исключений. Нет, конечно они все стандартны и можно было бы вывести строку ошибки, но... но нужно ещё кучи доп информации.

[Old]

1) Читайте внимательнее. Там написано что обработка не исключительных ситуаций при помощи исключений и далее текст цитаты. Т.е. применение исключений везде даёт худший результат,чем совмещение разных подходов.

Не вижу обоснований из чего это следует.

2) писал. Qt/C++/Boost/*** (секретная разработка )/OPC. Примерно 8 блоков для обработки исключений. Нет, конечно они все стандартны и можно было бы вывести строку ошибки, но... но нужно ещё кучи доп информации.

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

[Bepec]

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

PS код привести не могу, ком.тайна. Да и уволился с того места работы.

[Old]

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

Скорее это из-за того, что по теме сказать нечего из-за не владения предметом. А отписаться в теме захотелось.

PS код привести не могу, ком.тайна. Да и уволился с того места работы.

Другого ответа я и не ожидал.
Хотя я код приводить не просил, просто вымышленный пример. Ну да ладно.

[OKTA]

А на сколько человечно делать грубо говоря try на весь main, чтобы не плодить код? При условии, что есть нормальная система обработки всех сгенерированных исключений? И на сколько человечно использовать исключения в конструкторах и деструкторах. Знаю, что все настоятельно рекомендуют не делать этого, т.к. исключение прерывает нормальных ход выполнения, но если использовать исключения в конце конструкторов-деструкторов после всех выполненных методов, когда мы точно уверены, что все уже ок и просто хотим получить уведомление об этом?

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

[Old]

А на сколько человечно делать грубо говоря try на весь main, чтобы не плодить код? При условии, что есть нормальная система обработки всех сгенерированных исключений?

В main catch это последняя линия, если сюда попали, то сделать уже ничего нельзя и остается вывести диагностику и остановиться. Это ничем не отличается от вываливания в main из 100500 вложенной функции постоянно проверяю ошибку и делая return вверх.
Если мы можем как то повлиять на ситуацию, то обрабатываем это в локальной секции catch.

И на сколько человечно использовать исключения в конструкторах и деструкторах.

В конструкторах вполне "человечно", если правильно инициализировать члены класса.
В деструкторах не стоит использовать, но если понимать в чем могут быть проблемы и организационно не допускать таких случаев, то можно и в деструторах.

[8Observer8]

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

Долго думал по поводу этого тезиса, но так его и не понял. Если я написал функцию и в объявлении написал, какие исключения она выбрасывает:

Код

C++ (Qt)
void readData( const QString &fileName, QVector<int> &arr ) throw (FileOpenError, FileReadError);
 

и ещё знаю, что оба эти исключения и FileOpenError и FileReadError наследуются от FileError, то могу отлавливать оба этих исключения одним блоком try/catch:

Код

C++ (Qt)
    try {
        readData( iFileName, arr );
    } catch ( const FileError &e ) {
        std::cerr << e.what( ) << std::endl;
        return 1;
    }
 

Таким образом исключение от меня ускользнуть не может. Большинство функции STD генерируют исключения и я так понимаю, что надо учиться все их обрабатывать. К примеру, мы выделяем память из кучи и слишком много запросили (или может случайно в цикле это начали делать). Вот такой пример из книги, когда памяти не хватает, то new выбрасывает исключение std::bad_alloc. И нам обязательно надо его обработать, чтобы программа не завершилась без всяких сообщений:

Код

C++ (Qt)
#include <iostream>
 
int main( ) {
    int* ptr;
    int numInts = 10;
 
    try {
        ptr = new int[numInts];
    } catch ( const std::bad_alloc& e ) {
        std::cerr << __FILE__ << "(" << __LINE__ << "): Unable to allocate memory!" << std::endl;
        // Handle memory allocation failure
        return 1;
    }
    // Proceed with function that assumes memory has been allocated
 
    return 0;
}

А если мы не хотим в данном случае получать исключения, то надо написать: new(nothrow), тогда будет возвращено: nullptr:

Код

C++ (Qt)
#include <iostream>
 
int main( ) {
    int* ptr;
    int numInts = 10;
 
    ptr = new(std::nothrow) int[numInts];
    if ( ptr == nullptr ) {
        std::cerr << __FILE__ << "(" << __LINE__ << "): Unable to allocate memory!" << std::endl;
        // Handle memory allocation failure
        return 1;
    }
    // Proceed with function that assumes memory has been allocated
 
    return 0;
}
 

Вот только nullptr - это из C++11. А что написать вместо nullptr для C++98?

[Old]

Вот только nullptr - это из C++11. А что написать вместо nullptr для C++98?

0

[8Observer8]

Спасибо

[Bepec]

Всегда есть шанс не вспомнить какое нибудь исключение из далёкого класса. Да, когда их 5-10-30 достаточно их все помнить. А когда их станет больше, можно и забыть. И будет "вылет без всяких сообщений".

[Old]

И будет "вылет без всяких сообщений".

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