Другие способы обработки ошибок
Механизм особых ситуаций нужен для того, чтобы из одной части программы можно было сообщить в другую о возникновении в первой "особой ситуации". При этом предполагается, что части программы написаны независимо друг от друга, и в той части, которая обрабатывает особую ситуацию, возможна осмысленная реакция на ошибку.
Как же должен быть устроен обработчик особой ситуации? Приведем несколько вариантов:
int f(int arg) { try { g(arg); } catch (x1) { // исправить ошибку и повторить g(arg); } catch (x2) { // произвести вычисления и вернуть результат return 2; } catch (x3) { // передать ошибку throw; } catch (x4) { // вместо x4 запустить другую особую ситуацию throw xxii; } catch (x5) { // исправить ошибку и продолжить со следующего оператора } catch (...) { // отказ от обработки ошибки terminate(); } // ... }
Укажем, что в обработчике доступны переменные из области видимости, содержащей проверяемый блок этого обработчика. Переменные, описанные в других обработчиках или других проверяемых блоках, конечно, недоступны:
void f() { int i1; // ... try { int i2; // ... } catch (x1) { int i3; // ... } catch (x4) { i1 = 1; // нормально i2 = 2; // ошибка: i2 здесь невидимо i3 = 3; // ошибка: i3 здесь невидимо } }
Нужна общая стратегия для эффективного использования обработчиков в программе. Все компоненты программы должны согласованно использовать особые ситуации и иметь общую часть для обработки ошибок. Механизм обработки особых ситуаций является нелокальным по своей сути, поэтому так важно придерживаться общей стратегии. Это предполагает, что стратегия обработки ошибок должна разрабатываться на самых ранних стадиях проектах. Кроме того, эта стратегия должна быть простой (по сравнению со сложностью всей программы) и ясной. Последовательно проводить сложную стратегию в такой сложной по своей природе области программирования, как восстановление после ошибок, будет просто невозможно.
Прежде всего стоит сразу отказаться от того, что одно средство или один прием можно применять для обработки всех ошибок. Это только усложнит систему. Удачная система, обладающая устойчивостью к ошибкам, должна строиться как многоуровневая. На каждом уровне надо обрабатывать настолько много ошибок, насколько это возможно без нарушения структуры системы, оставляя обработку других ошибок более высоким уровням. Назначение terminate() поддержать такой подход, предоставляя возможность экстренного выхода из такого положения, когда нарушен сам механизм обработки особых ситуаций, или когда он используется полностью, но особая ситуация оказалась неперехваченной. Функция unexpected() предназначена для выхода из такого положения, когда не сработало основанное на описании всех особых ситуаций средство защиты. Это средство можно представлять как брандмауер, т.е. стену, окружающую каждую функцию, и препятствующую распространению ошибки. Попытка проводить в каждой функции полный контроль, чтобы иметь гарантию, что функция либо успешно завершится, либо закончится неудачно, но одним из определенных и корректных способов, не может принести успех. Причины этого могут быть различными для разных программ, но для больших программ можно назвать следующие:
- работа, которую нужно провести, чтобы гарантировать надежность каждой функции, слишком велика, и поэтому ее не удастся провести достаточно последовательно;
- появятся слишком большие дополнительные расходы памяти и времени, которые будут недопустимы для нормальной работы системы (будет тенденция неоднократно проверять на одну и ту же ошибку, а значит постоянно будут проверяться переменные с правильными значениями);
- таким ограничениям не будут подчиняться функции, написанные на других языках;
- такое понятие надежности является чисто локальным и оно настолько усложняет систему, что становится дополнительной нагрузкой для ее общей надежности.
Однако, разбить программу на отдельные подсистемы, которые либо успешно завершаются, либо заканчиваются неудачно, но одним из определенных и корректных способов, вполне возможно, важно и даже выгодно. Таким свойством должны обладать основные библиотеки, подсистемы или ключевые функции. Описание особых ситуаций должно входить в интерфейсы таких библиотек или подсистем.
Иногда приходится от одного стиля реакции на ошибку переходить на другой. Например, можно после вызова стандартной функции С проверять значение errno и, возможно, запускать особую ситуацию, а можно, наоборот, перехватывать особую ситуацию и устанавливать значение errno перед выходом из стандартной функции в С-программу:
void callC() { errno = 0; cfunction(); if (errno) throw some_exception(errno); }
void fromC() { try { c_pl_pl_function(); } catch (...) { errno = E_CPLPLFCTBLEWIT; } }
При такой смене стилей важно быть последовательным, чтобы изменение реакции на ошибку было полным.
Обработка ошибок должна быть, насколько это возможно, строго иерархической системой. Если в функции обнаружена динамическая ошибка, то не нужно обращаться за помощью для восстановления или выделения ресурсов к вызывающей функции. При таких обращениях в структуре системы возникают циклические зависимости, в результате чего ее труднее понять, и возможно возникновение бесконечных циклов в процессе обработки и восстановления после ошибки.
Чтобы часть программы, предназначенная для обработки ошибок была более упорядоченной, стоит применять такие упрощающие дело приемы, как "запрос ресурсов путем инициализации", и исходить из таких упрощающих дело допущений, что "особые ситуации являются ошибками".
