Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Все ошибки располагаются на побочных маршрутах, которые располагаются справа от главного маршрута.
ВП>Правило ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ.
Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно. Каждый раз явно нужно инициировать проверки, что легко забыть. Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал. Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д. Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут? Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

И далее. Что то мне подсказывает, что автогенеренный код будет просто ужасен, и его будет крайне проблематично читать текстом. А читать текстом в любом случае придется, ибо детали реализации даже если на схеме и будут показаны, то будут разбросаны на практике по разным листам. Мне, например, весьма интересно, как на практике алгоритм "Свари кашу" будет уведомлять родительский алгоритм о том, что каша подгорела. Явный возврат контекста, содержащего результат выполнения и возможные проблемы? Если такое делать для всех, то получим весьма неслабый оверхед. Глобальные переменные какие? Или не глобальные, а алгоритм представляет собой объект, у которого можно выполнить метод execute, а потом вернуть проблемы и результаты? А если мы генерим Фортран код?