Здравствуйте, elmal, Вы писали:

E>Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно.

Да, Вы правы. Все надо задавать ЯВНО.

E>Каждый раз явно нужно инициировать проверки, что легко забыть.

Слова «легко забыть» говорят о серьезной опасности.
Можно ли принять меры против этой опасности?

Да, можно. Для этого надо решительно отобрать эту работу у постороннего человека (программиста, потому что он не в курсе дела) и передать ее компетентному человеку, то есть инженеру.

Почему? Потому что первоисточником знаний является инженер. Инженер стоит на высшей ступени знаний. Он знает данный вопрос (как обрабатывать ошибки) намного лучше, чем программист. Программист получает знания от инженера.

В основе технологии Графит-Флокс лежит принцип:

КТО ОБЛАДАЕТ ЗНАНИЯМИ, ТОТ И ДОЛЖЕН ИХ ФОРМАЛИЗОВАТЬ.

Это принцип позволяет создать наиболее надежную защиту от такого несчастья, как «легко забыть».

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

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

E>Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал.

Это дело инженера. Как он решит, так и правильно. Учтем также, что у инженера есть начальник лаборатории. Последнее слово за начальником лаборатории. Программисты здесь ни при чем. Если начальник лаборатории посчитает нужным, он может сходить к программистам посоветоваться. Но решение принимают не программисты, а инженеры. Никто лучше их не знает, какие могут быть ошибки и что с ними делать.

E>Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д.

Этого не может быть. Работа распределена между отделами, а внутри отдела между лабораториями. Невозможно представить, чтобы какой-то партизан без разрешения начал действовать в чужом огороде.

E>Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут?

Система управления ракетой разделена на функциональные тракты. Тракты поделены между инженерными лабораториями. Внутри тракта хозяин инженер.

Если есть какой-то системный вопрос, относящийся к системному программированию, тут командуют программисты. (Это упрощенная схема, бывают исключения из правила).

E>Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

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

Если силуэт кажется перегруженным, его всегда можно разделить. Причем сделать это разными способами.

Ответ на Ваш второй абзац я дам позже

Мои ответы относятся только и исключительно к организации работ в НПЦАП при разработке системы управления ракет.