пример - класс exception c++




Когда вы должны создать свой собственный тип исключения? (4)

Использовать одно и то же исключение везде легко. Особенно при попытке поймать это исключение. К сожалению, это открывает двери для обработки исключений Pokemon. Это приносит риск ловли исключений, которые вы не ожидаете.

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

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

Я работаю над проектом, где мы реструктурируем старый код C в новый C ++, где для обработки ошибок мы используем исключения.

Мы создаем разные типы исключений для разных модулей.

Я не вижу в этом смысла, но у меня нет веских аргументов, чтобы доказать свою точку зрения. Так что, если бы мы написали стандартную библиотеку, вы бы увидели vector_exception, list_exception и так далее.

Размышляя об этом, я наткнулся на этот вопрос:

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

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


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

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

Нечестивый союз должен был бы построить иерархию исключений:

std::exception
  EXProjectBase
    EXModuleBase
      EXModule1
      EXModule2
    EXClassBase
      EXClassMemory
      EXClassBadArg
      EXClassDisconnect
      EXClassTooSoon
      EXClassTooLate

Затем настаивайте на том, что каждое действительное исключение происходит из ОБА и модуля и классификации. Затем вы можете поймать все, что имеет смысл для перехвата, например, разъединение, вместо необходимости отдельно перехватывать HighLevelDisconnect и LowLevelDisconnect.

С другой стороны, также совершенно справедливо предположить, что интерфейс HighLevel должен был полностью справляться со сбоями LowLevel, и их никогда не должен видеть клиент HighLevel API. Это где ловля по модулю была бы полезной последней чертой.


Я вижу две возможные причины.

1) Если вы хотите сохранить в классе исключений некоторую пользовательскую информацию об исключении, то вам нужно исключение с дополнительными элементами данных. Часто вы наследуете от одного из классов исключений std.

2) Если вы хотите различать исключения. Например, предположим, что у вас есть две разные invalid argument ситуации с invalid argument и в вашем блоке catch вы хотите иметь возможность различать эти две ситуации. Вы можете создать два дочерних класса std::invalid_argument


Я думаю, что помимо причин в других ответах может быть читаемость кода, потому что программисты тратят много времени на его поддержку. Рассмотрим два фрагмента кода (при условии, что они выдают ошибку «пустой кадр»):

void MyClass::function() noexcept(false) {

    // ...
    if (errorCondition) {
        throw std::exception("Error: empty frame");
    }
}
void MyClass::function() noexcept(false) {

    // ...
    if (errorCondition) {
        throw EmptyFrame();
    }
}

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





exception-handling