Когда и как ловить исключения

Question

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

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

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

Answer 1

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

Я дословно скопировал его резюме

Различают ошибки и nonerrors. Ошибка является ошибкой, если и только если это нарушает функцию способность встретить своих собеседников предпосылки, чтобы создать свою собственную постусловия, или восстановить инвариант разделяет ответственность за поддержание. Все остальное не ошибка.

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

Предпочитаю дополнительно гарантировать, что либо конечное состояние либо исходное состояние (если произошла ошибка, операция была отменена) или целевое целевое состояние (если не было ошибка, операция была совершена); это сильная гарантия.

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

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

Answer 2

Самый упрощенный совет:

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

Дело в том, что исключения являются исключительными (подумайте std::bad_alloc).Помимо некоторых странных применений для «быстрого выхода» глубоко вложенных блоков кода (что мне не очень нравится), исключения следует использовать только тогда, когда вы замечаете что-то, с чем не знаете, как иметь дело.

Давайте выберем примеры:

file = open('littlefile.txt', open.mode.Read)

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

В C ++ я написал бы такую ​​функцию как:

boost::variant<FileHandle,Error> open(std::string const& name, mode_t mode);

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

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

Подумайте об общем случае ассоциативного контейнера:

template <typename Key, typename Value>
boost::optional<Value const&> Associative::GetItem(Key const& key) const;

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

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

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

Я оставляю исключения для технических проблем (потеря соединения, нехватка памяти,и т.д ...).

Answer 3

Может быть этот раздел MSDN поможет вам ...

Answer 4

Прочтите главу «Обработка исключений» из книги

Мышление в C ++, Том 2 - Брюс Экель