Параллельное и распределенное программирование на С++

Итак, на рис. 7.7 показано три И-схемы, объединяемые на основе ИЛИ-отношений для получения результата S (который означает успешное завершение работы системы). Диаграмма событий (см. рис. 7.6) и логическая схема (см. рис. 7.7) — это примеры простых методов, которые можно использовать для визуализации критических путей (ветвей) и критических компонентов в некоторой части ПО. После идентификации критических путей и компонентов разработчик должен прелусмотреть ответные действия, которые должна выполнить система в случае, если откажет любой из критических компонентов. Если при этом используется модель завершения, то обработчик исключений не делает попытку возобновить выполнение ПО с точки, в которой возникла исключительная ситуация. Вместо этого осуществляется выход из функции или процедуры, в которой произошло исключение, и предпринимаются действия по пе-револу системы в стабильное (насколько это возможно) состояние. Но если используется модель возобновления, то корректируются условия, создавшие аномалию, и программа возобновляется с точки, в которой возникла исключительнал ситуация. Важно отметить, что при реализации модели возобновления возможны определенные трудности. Например, предположим, что наш код содержит слелующую последовательность вложенных вызовов процедур:

try{

А вызывает В

В вызывает С

С вызывает D

D вызывает E

E сталкивается с аномалией, с которой не может справиться

}

catch(exception Q) {

}

Если в процелуре E возникла аномалия и было сгенерировано исключение, то возможна проблема со стеком вызовов. Нужно также решить вопрос с разрушением объектов и проблему «подвешенных» значений, возвращаемых процедурами. Подумайте, что произойдет, если процедуры С и D являются рекурсивными? Даже если мы откорректируем условие, вызвавшее исключение в процедуре E, то как вернуть программу в состояние, в котором она пребывала непосредственно перед выбросом исключения? А ведь мы должны сохранить информацию в стеке, таблицы создания и разрушения объектов, таблицы прерываний и пр. Это потребует больших затрат и обеспечения сложного взаимодействия между вызывающими и вызываемыми сторонами. Bce вышесказанное обозначило лишь поверхностный слой трудностей. Из-за сложности реализации модели возобновления и благодаря тому факту, что разработка больших систем может обойтись без нее, для С++ была выбрана модель завершения. В книге [44] Страуструп дает полное обоснование того, почему комитет ANSI в конце концов выбрал для механизма обработки исключений модель завершения. Но если, несмотря на то что модель возобновления действительно сопряжена с большими трудностями, надежность и бесперебойность ПО являются критичными факторами, то лля реализации этой модели все же имеет смысл приложить соответствующие усилия. При этом стоит иметь в виду, что С++-средства обработки исключений можно использовать и для реализации модели возобновления.

Резюме

Создание надежного ПО — серьезное занятие. К вопросам обработки исключительных ситуаций и исправления ошибок следует подходить с особой ответственностью. Тщательное тестирование и отладка каждого компонента ПО должны быть основными средствами защиты от программных дефектов. Обработку исключений необходимо внести в систему или подсистему ПО после того, как оно прошло этап строжайшего тестирования. Механизм генерирования исключений не следует использовать в качестве общего правила для обработки ошибок, поскольку он нарушает обычный ход выполнения программы. К средствам генерирования исключений следует прибегать только после того, как будут исчерпаны все остальные меры. Программист, который планирует проектировать более полные и полезные (с его точки зрения) классы исключений, должен использовать стандартные классы обработки исключений в качестве архитектурных «дорожных карт». Стандартные классы, не специализированные с помощью наследования, могут лишь уведомлять об ошибках. Можно создать более полезные классы исключений, которые бы обладали корректирующими функциями и большей информативностью. В общем случае, как модель завершения, так и модель возобновления позволяют продолжать выполнение программы. Обе эти модели предлагают альтернативу простому прерыванию программы при обнаружении ошибки. Более полное рассмотрение темы обработки исключительных ситуаций можно найти в работе [44].

Распределенное объектно-ориентированное программирование

Итак, основное различие между человеком и андроидом состоит в том, что человек приходит со своим собственным «я», чего нельзя сказать о роботе.

— Кэри де Бессонет(Cary G deBessonet), Towards А Sentential 'Reality' for the Android