Камерон Хьюз - Параллельное и распределенное программирование на С++

if <���входные данные неприемлемы, то>

<���повторно запрашиваем входные данные>

else

<���выполняем нужную операцию> end if

Такая проверка условий — одна из основополагающих граней искусства программирования. Продемонстрированный стиль программирования позволяет не допустить возникновения многих проблем, но эта модель ситуации не «дотягивает» до определения исключительной. Существуют различия между дефектами и исключительными ситуациями, а также между исключительными ситуациями и нежелательными условиями. С дефектами справляются путем тестирования и отладки. Нежелательные условия обрабатываются в рамках обычной программной логики, а исключительные ситуации — методами обработки исключений. Различия между характеристиками обработки ошибок, исключений и нежелательныхусловий сведены в табл. 7.2.

Таблица7.2. Различия между характеристиками обработки ошибок, исключений и нежелательных условий

Наша цель — так построить компоненты обработки ошибок и обработки исключений, чтобы затем их можно было объединить с другими компонентами, составляющими параллельные или распределенные приложения. Эти компоненты должны обладать средствами идентификации проблем и уведомления о них, а также возможностями их корректировки или восстановления работоспособности приложения. Под восстановлением и корректировкой подразумеваются самые различные способы достижения поставленной цели: от предложения пользователю еще раз ввести данные (с подсказкой, например, их правильного формата) до перезагрузки подсистемы в рамках ПО. Действия по восстановлению и корректировке могут включать обработку файлов, возврат из базы данных, изменение сетевого маршрута, маскирование процессоров, повторную инициализацию устройств, а для некоторых систем даже замену элементов оборудования. Компоненты обработки ошибок и исключительных ситуаций могут быть выполнены в различных формах: от простых предписаний до интеллектуальных агентов, единственное назначение которых состоит в предвидении ситуаций сбоя и их предотвращении. Компонентам обработки ошибок и исключений в ответственных участках ПО уделяется значительное внимание. Архитектура упрощенного компонента обработки ошибок представлена на рис. 7.3.

Компонент 1 на рис. 7.3— это простой компонент отображения (map), который содержит список номеров ошибок и их описания. Компонент 2 содержит объект, который преобразует номера ошибок в адреса переходов, функций или подсистем. По номеру ошибки компонент 2 определяет направление перехода. Компонент 3 преобразует номера ошибок в иерархическую структуру отчетов и логику отчетов. Иерархическая структура отчетов содержит данные о том, кого (или что) необходимо уведомить об ошибке. Логика отчетов определяет, что должно включать это уведомление. Компонент 4 содержит два объекта отображения. Первый преобразует номера ошибок в объекты, назначение которых — скорректировать некоторые ситуации сбоя (условия). Второй преобразует номера ошибок в объекты, которые возвращают систему в стабильное или хотя бы частично стабильное состояние. Упрощенный компонент обработки ошибок, показанный на рис. 7.3, можно применить к ПО любого размера и формы. Характер использования компонентов обработки ошибок и исключительных ситуаций определяется требуемой степенью надежности ПО.

Напомним, что мы различаем ошибочные и неудобные (нежелательные) условия. Неудобные или нежелательные условия должны обрабатываться обычной программной логикой. Ошибки (дефекты) требуют специального программирования. В книге Страуструпа Язык программирования С++ (1997) автор приводит четыре основных альтернативных действия, которые может предпринять программа при обнаружении ошибки. По мнению Страуструпа, программа, выявив проблему, которую невозможно обработатьлогически, должна реализовать один из следующих вариантов поведения.

• Вариант1. Завершить программу.

• Вариант 2. Возвратить значение, обозначающее «ошибку».

• Вариант 3. Возвратить значение, обозначающее нормальное завершение, и оставить программу в состоянии с необработанной ошибкой.

• Вариант 4. Вызвать функцию, предназначенную для вызова в случае ошибки.

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

Очевидно, что завершать программу при каждом обнаружении ошибки попросту неприемлемо. Здесь мы согласны со Страуструпом. В таких случалх следует поступать более изобретательно. Что касается варианта 2, то примитивный возврат значения ошибки действительно может помочь в некоторых ситуациях, но далеко не во всех. Не каждое возвращаемое значение может интерпретироваться как успешное или неудачное. Например, если значение, возвращаемое некоторой функцией, имеет вещественный тип, и область определения функции включает как отрицательные, так и положительные значения, то какое тогда значение функции можно использовать для представления ошибки? Другими словами, это не всегда возможно. С нашей точки зрения, вариант 3 также неприемлем. Ведь если «изготовитель» возвращает значение, обозначающее нормальное завершение, «потребитель» продолжит работу, предположив, что его запрос был выполнен, а это может вызвать еще большие проблемы. Осталось рассмотреть вариант 4. Он требует более внимательного подхода при обсуждении обработки как ошибок, так и исключительных ситуаций.