Стратегия обработки ошибок пользователя с помощью собственных классов исключений

[Bepec]

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

[Igors]

То что в проекте становится побольше классов, после введения этой концепции, так это не проблема, а преимущество. Разделяй и властвуй!

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

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

- что делают эти многочисленные классы? Печатают ошибки. Это место весьма уязвимо. Нужна или печать в юникоде, или в национальном алфавите или вообще "другая". Напр Вы сочли разумным сообщать имя ф-ции. Но др разработчик может так не считать, напр зачем в месяге для юзера имя ф-ции? И что тогда? Лезть и переделывать весь Ваш дизайн? Стандартный подход: код ошибки + доп данные (часто имя файла) + строка ошибки по умолчанию. И обработчик исключений уже решит что показывать юзверю: то ли сам напечатает, то ли Ваше или вообще ничего

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

[8Observer8]

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

Я подправил, чтобы было ясно:

Об этой стратегии обработки ошибок пользователя я прочитал в книге Professional C++ (2nd Edition) Скачать книгу (99МБ)+код к книге (464КБ) одним архивом (90МБ): https://yadi.sk/d/VCvsky11c6wtP Подробное описание создания собственных классов исключений находится здесь: "Chapter 10. Handling Errors" -> "Exceptions and Polymorphism" -> "Writing Your Own Exception Classes"

[8Observer8]

Функция printArray принимает массив и выбрасывает исключение EmptyError, если входной аргумент пуст:

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

Я рассматриваю исключения, как способ показать пользователю, почему завершилась программа. Показать ему текст. Я имею ввиду не только конечного пользователя приложения, но и пользователя класса. Это лучше, чем пользователь увидит креш, который не даст информацию ни ему, ни разработчику. Отловленные ошибки, на мой взгляд, лучше сохранять в лог с полной информацией об источнике (Класс::функция, пояснение о недопустимых параметрах с выводом этих параметров). Хотите ли вы или нет, но большинство функций STL выбрасывает исключения. Для таких функция нужно писать обёртку в виде класса. Может конечно наступит время, когда в Qt будут аналоги абсолютно всех STL функций, которые будут безопасны относительно исключений, но пока такого не произошло. Исключения необходимо отлавливать, показывать пользователю текст ошибки (записывать в лог). Тогда пользователь сможет обратиться к разработчику, а тот сможет быстро найти источник ошибки, так как будет знать какая функция выбросила исключение, тип исключения и какие условия к этому привели

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

Цитата из моей темы: http://www.prog.org.ru/topic_26723_0.html

1) Функция возвращает 0 при отсутствии ошибок и -1 в случае ошибки. Посмотреть код ошибки можно с помощью глобальной переменной errno (глобальной для потока). Значение функции возвращаем через ссылку-параметр функции.

2) Функция возвращает 0 в случае ошибки, так как 0 в C и C++ - это false. Функцию, тогда можно вызывать так: if ( func( ) ). Посмотреть код ошибки можно с помощью глобальной переменной errno. Значение функции возвращаем через ссылку-параметр функции.

3) Функция возвращает, как значение, так и код ошибки через структуру, либо класс, либо std::pair, либо std::tuple

4) Слышал, есть ещё способ с nullptr. Но так пример и не нашёл.

5) Ещё я слышал есть механизм setjmp()/longjmp(). Но его в C++ нельзя использовать, там какая-то замута с конструкторами, деструкторами и стеком. Да и в C его не используют (или не рекомендуют)

6) Функция возвращает 0 при отсутствии ошибок и код ошибки (errno не используется). Значение функции возвращаем через ссылку-параметр функции (можно сделать наоборот, что функция будет возвращать значение, а код ошибки через ссылку-параметр).

[Igors]

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

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

Вот Вы рассказываете как хороши классы исключений. Давайте зарядим на каждый случай свой класс! В действительности это достаточно спорно/проблематично. Напр я (и полагаю - не только) совсем не горю желанием иметь батарею catch'ей. Ну если где-то в одном месте - ладно, потерплю. Но если во многих - это так загадит код что он станет невыносимым. Не надо спешить с выводами (тем более в виде статей) всего лишь прочитав книжку (пусть самую хорошую).

[vulko]

В каждом конкретном случае выбор способа обработки ошибок требует интуиции

Фраза века!

В каждом конкретном случае говнокодинг и говнофиксинг требует интуиции. Потому что если анализировать и думать, то наговнокодить сложнее. А тут интуитивно понатыкал говнокода, а вдруг пофиксится!))
Индусы именно так и работают)))

[Bepec]

Vulko а вот тут вы неправы. Igors дело говорит. А уж Observer для меня стал нарицательным именем

[vulko]

Vulko а вот тут вы неправы. Igors дело говорит. А уж Observer для меня стал нарицательным именем

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

Но вот про интуицию это конечно ппц)))
Вопрос заключается в том нужны ли они для разработчика/юзера или не нужны.
И ответ зависит лишь от того, возможны ли потенциальные ошибки в рантайме. Например юзер ввел неверно что-то. Программист вышел за пределы массива. И т.п.
Причем ошибки юзера можно свести на нет проверками, исключения не особо нужны. Остаются разработчики. Если для разработчика АПИ будет скрыто, неплохо бы добавить исключения. А если для разработчика оно открыто, то не обязательно.

Какая нафик интуиция вообще?!

[8Observer8]

Напр я (и полагаю - не только) совсем не горю желанием иметь батарею catch'ей

Их можно все унаследовать от одного класса, например, пусть он называется LogicError:

Код

C++ (Qt)
    try {
        // Parse the person array to the Json-content
        QJsonDocument content;
        parsePersonsToContent( persons, content );
    } catch ( const LogicError &e ) {
        std::cerr << e.what( ) << std::endl;
        return 1;
    }
    catch ( ... ) {
        std::cerr << "Error: unknown exception" << std::endl;
        return 1;
    }

Опять же повторюсь, что это способ завершить программу без креша, и с максимально полной информацией. Конечно же, если команда конкретной фирмы за это, то здорово! А когда один работаешь, то ещё лучше. Мне лично пока такая схема очень нравится. Пока не вижу в ней недостатков, так как не видел конкретных ситуаций, примеров. На мой взляд, такая схема завершения без креша намного лучше, чем придумывать свою схему возвращения кодов ошибок. О вкусах не спорят

[8Observer8]

Qt возвращает коды ошибок - прекрасно! Можно написать обёртку, которая выкидывает исключение. Но я далеко не всегда так делаю. Просто показываю сообщение QMessageBox. Ошибки нужно обрабатывать всегда, но комбинировать намного лучше, чем следовать одной догме. В одном месте программы мне удобно показать QMessageBox с текстом "Некорректны ввод. Введите снова" без всяких исключений. А вот в другом месте программы я вызываю метод своего объекта. Я знаю, что он выбрасывает исключения унаследованные от класса LogicError. Я пишу вызов метода в блоке try{}. Показал текст, который выбросило исключение в QMessageBox (сохранил в лог), завершил приложение

[Igors]

Их можно все унаследовать от одного класса, например, пусть он называется LogicError:

Код

C++ (Qt)
    try {
        // Parse the person array to the Json-content
        QJsonDocument content;
        parsePersonsToContent( persons, content );
    } catch ( const LogicError &e ) {
        std::cerr << e.what( ) << std::endl;
        return 1;
    }
    catch ( ... ) {
        std::cerr << "Error: unknown exception" << std::endl;
        return 1;
    }

А тогда чего городились многочисленные классы? Типа - захочет, пусть разбирается с каждым в своем catch, а нет - вывел общую ошибку (как здесь) и все. Не так ли ?   Но это неудачно (или просто неверно), если интересно объясню почему.

[8Observer8]

А тогда чего городились многочисленные классы?

Классы городились, потому что там текст разный и параметры конструкторы могут разные принимать. И для удобства различия по имени. Наследуются от одного или от разных классов по связи, чтобы catch'ев много не писать. Вот у меня в проекте есть базовый класс FileError, а от него наследуются: FileOpenError, FileWriteError, FileReadError, которые содержат просто разный текст и в качестве параметра конструкторам передаётся имя функции, которое выбросило исключение. Текст показали, завершили приложение

[Igors]

Классы городились, потому что там текст разный ..

Это плохое, поверхностное решение

[Bepec]

to Vulko:
Именно интуиция разработчика позволяет создать универсальное и легковесное решение
Разработчику без интуиции очень сложно, я бы сказал невозможно жить

PS почитайте что такое интуиция и с удивлением поймёте, что интуиция есть результат осмысления опыта

[Old]

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

Но это неудачно (или просто неверно), если интересно объясню почему.

Конечно, будьте любезны обьяснить свои фантазии.