Не избегайте исключений
Причина
Кажется, есть четыре основные причины, приводимые для неиспользования исключений:
- исключения неэффективны
- исключения приводят к утечкам и ошибкам
- производительность исключения не предсказуема
- поддержка времени выполнения обработки исключений занимает слишком много места
Нет способа, которым мы можем урегулировать этот вопрос к удовлетворению всех. Ведь обсуждения об исключениях идут более 40 лет. Некоторые языки не могут быть использованы без исключений, но другие их не поддерживают. Это приводит к сильным традициям использования и неиспользования исключений, и к ожесточённым дебатам.
Однако мы можем кратко изложить, почему мы считаем исключения лучшей альтернативой для программирования общего назначения и в контексте этих руководств. Простые аргументы за и против часто неубедительны. Есть специализированные приложения, где исключения действительно могут быть неуместны (например, жёсткие системы реального времени без поддержки надёжной оценки стоимости обработки исключения).
Рассмотрим основные возражения против исключений по очереди
По сравнению с чем? При сравнении убедитесь, что обрабатывается один и тот же набор ошибок и что они обрабатываются эквивалентно. В частности, не сравнивайте программу, которая немедленно прекращает работу при виде ошибки, с программой которая тщательно очищает ресурсы перед регистрацией ошибки. Да, некоторые системы имеют плохие реализации обработки исключений; иногда такие реализации вынуждают нас использовать другие подходы обработки ошибок, но это не фундаментальная проблема с исключениями. При использовании аргумента эффективности - в любом контексте - будьте осторожны, что у вас есть хорошие данные, которые действительно предоставляют возможность в обсуждаемую проблему.
Они этого не делают. Если ваша программа - это крысёнок указателей без общей стратегии управления ресурсами, у вас есть проблема, что бы вы ни делали. Если ваша система состоит из миллиона строк такого кода, вы вероятно не сможете использовать исключения, но это проблема с чрезмерным и неорганизованным использованием указателей, а не с исключениями. На нашу думку, вам нужен RAII, чтобы сделать обработку ошибок на основе исключений простой и безопасной -- проще и безопаснее, чем альтернативы.
Если вы находитесь в жёсткой системе реального времени, где вы должны гарантировать выполнение задачи в данное время, вам нужны инструменты для поддержки таких гарантий. Насколько нам известно, такие инструменты недоступны (по крайней мере для большинства программистов).
Это может быть случай в малых (обычно встроенных) системах. Однако перед отказом от исключений рассмотрите, какое место потребует последовательная обработка ошибок с использованием кодов ошибок и какова стоимость отказа поймать ошибку.
- Исключения неэффективны:
- Исключения приводят к утечкам и ошибкам.
- Производительность исключения не предсказуема.
- Поддержка времени выполнения обработки исключений занимает слишком много места.
Много, возможно, большинство проблем с исключениями происходят из исторических потребностей взаимодействовать с запутанным старым кодом.
Фундаментальные аргументы за использование исключений:
- Они чётко различают ошибочный возврат от обычного возврата
- Они не могут быть забыты или проигнорированы
- Они могут быть использованы систематически
Помните
- Исключения предназначены для отчётности об ошибках (в C++; другие языки могут иметь другое использование для исключений).
- Исключения не для ошибок, которые могут быть обработаны локально.
- Не пытайтесь поймать каждое исключение в каждой функции (это скучно, неуклюже, и приводит к медленному коду).
- Исключения не для ошибок, требующих мгновенного прекращения модуля/системы после невосстановимой ошибки.
Пример
???
Альтернатива
- RAII
- Контракты/утверждения: Используйте
ExpectsиEnsuresGSL (до тех пор, пока мы не получим языковую поддержку для контрактов)