Я знаю много программистов, и все они по-разному отзываются об обработке исключительных ситуаций. Некоторые из них говорят, что это единственный способ написать безошибочный код. Другие настаивают на том, что обработка исключительных ситуаций - это работа дьявола, так же, как goto и непродуманные оптимизации. Защитники говорят, что обработка исключительных ситуаций делает ваш код более крепким и проще поддерживаемым. Когда дело доходит до обработки исключительных ситуаций, я предпочитаю оставаться где-то между этими двумя слегка склоняясь к «крепости
защитников».

Правила для использования обработки исключительных ситуаций. Я думаю, что обработка исключительных ситуаций сделает ваш код проще в чтении и в написании, если вы будете соблюдать некоторые золотые правила. Если вы пишете throw, пишите и catch, когда возникает непредвиденная операция, а не когда происходит что-то плохое, но вероятное. Используйте throw, когда возникает непредвиденная операция. Пишите для ошибок catch так рано, как это возможно, но не раньше.

Если вы пишете throw, пишите и catch. Другими словами, когда вы пишете блок, где могут появиться ошибки, вы должны также озаботиться написанием блока, где они будут отслеживаться, и решить, что будет происходить при их обнаружении. Любая возникшая ошибка, которая не обнаружена вашей программой — это «необработанная исключительная ситуация», которая заставляет вашу программу работать медленнее, выдавая сообщающий об ошибке. Я видел много хороших программистов, которые наудачу писали код, который разваливался только потому, что сравнительно безобидная исключительная ситуация «ускользала», не будучи обнаруженной. Это правило также очень важно, когда вы имеете дело с большим базовым кодом, который не использует исключительных ситуаций.

Если вы пишете throw, пишите и catch, когда возникает непредвиденная операция, а не когда происходит что-то плохое, но вероятное. Чеширский кот сформулировал бы это правило так: обработка исключительных ситуаций занимается исключительными ситуациями. Она не обрабатывает неприятности, которые в принципе часто встречаются. Классический пример этого правила - чья-то попытка войти на сервер. Есть два привычных пути выполнения: или сервер позволяет пользователю войти, или сервер отказывает ему в доступе. Эти два пути кода должны быть обработаны без исключительных ситуаций (например, возвращением true при разрешении на доступ и false - при отказе).

С другой стороны, может возникнуть исключительная ситуация, если сервер возвращает «мусор»: он не говорит «да», не говорит «нет» — он говорит какую-то белиберду. В таком случае использование throw для исключительной ситуации оправдано, потому что ситуация действительно ненормальна: проблемы у пользователя гораздо серьезнее, чем просто неправильный ввод пароля. Другие исключительные ситуации могут включать в себя невозможность клиента соединиться с сервером, исчерпанность свободной памяти или невозможность послать данные.

Зачем следовать этому правилу? Для начинающих обработка исключительных ситуаций очень медленна. Люди, которые писали ваш компилятор С++, предполагали, что вы не будете использовать throw, если что-то не будет совсем плохо, но в этом случае, если заботиться, чтобы не было медленно, все просто сломается. Честно говоря, я не знаю, думали ли они об этом на самом деле, но по причине обработка исключительной ситуации с помощью throw действительно очень медленная. Другая причина (если она вам еще нужна!) в том, что частое использование исключительных ситуаций делает код трудным для прочтения. В общем-то, все важное было сказано уже пару абзацев назад.