Методы разработки устойчивого кода

25.2.2. Обработка исключений

В C++, C# и Java механизм допущений был значительно расширен. При возникновении неверных данных в критической точке вызывается не единая общесистемная функция, прерывающая выполнение программы, а пользовательская функция, которая может либо предпринять попытку разрешить проблему с данными, либо прервать выполнение программы. Возникновение проблемы в критической точке получило название исключительной ситуации или исключения, а вызываемая функция пользователя - обработчик исключения.

Рассмотрим класс, реализующий тип данных "вектор". Для получения значения элемента вектора в нем перегружается оператор [], в котором делается проверка допустимости значения индекса элемента. В качестве второго параметра функции Assert указывается метод класса, обрабатывающего исключительную ситуацию в случае, если значение индекса элемента недопустимо.

class safeVector : public vector {
public:
  class outOfRangeException {
    int l;
  public:
    outOfRangeException (const char *,
      const char *, int line)
      : l (line) {}
    int line (void) { return l; }
  };
  int& safeVector::operator[] (int index) {
    Assert ((index >= 0) && (index < size),
    safeVector::outOfRangeException);
...
};

int process(safeVector &v, int index) {
  int elem;
  try {
    elem = v[index];
  }

  catch (safeVector::outOfRangeException &e) {
    cerr   << "Safe Vector range exception:\n";
    exit (1);
  }
  return elem;
}

Для того, чтобы обработчик исключения сработал, обращение к элементу массива помещается внутрь структурного блока try { }, где содержатся команды, результат выполнения которых потенциально может вызвать исключительную ситуацию. Затем внутри синтаксического блока catch { } определяется реакция на возникшую исключительную ситуацию outOfRangeException. Подобным образом можно определить реакцию на любую исключительную ситуацию.

Все исключительные ситуации, для которых определяются пользовательские функции-обработчики, должны быть описаны в проектной документации и протестированы. Хорошей практикой является создание отдельной группы тестов, которая генерирует различные исключительные ситуации и проверяет реакцию системы на них. Однако следует учесть, что не все исключительные ситуации могут быть промоделированы при тестировании, особенно интеграционном или системном - некоторые обработчики пишутся "про запас", на случай изменения других модулей системы и в реальности никогда не вызываются.

25.2.3. Сбор и обработка информации о сбоях и отказах

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

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

Для упрощения работы службы поддержки и программистов рекомендуется включать в отчет служебную информацию о состоянии и окружении системы в момент сбоя - переменных окружения, активных объектах, состоянии сеанса пользователя и т.п.

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