DRAKON.SU

Здесь обсуждались ДРАКОН алгоритмы обработки исключений на DELPHI.

И как по этой схеме понять, откуда начинать смотреть в случае исключения? Целевая точка может быть на любой схеме "вышестоящего" уровня и все их надо просматривать последовательно в поисках обработчика. По-моему, не похоже на симультантное восприяетие.

Эти варианты алгоритмов:
- Выводят обработку исключений из главного шампура обработки данных, то есть работает принцип Дракона "чем хуже, тем правее". Восприятие улучшается.
- Состояние исключения фиксируется оператором "Try", что отображается иконой типа "Вопрос". При наличии исключения, управление передается на оператор "Except" или "Finally".
- В сообщении, AIN рассказал, что при выполнении оператора "Exit"-выход из процедуры между операторов "Try" и "Finally", выход не производится, а управление передается на оператор "Finally". Это и позволяет организовать при множественных "Exit" общий выход. Применение можно видеть в примере.

Какой Вы предлагаете способ поиска/отображения в схемах точки перехода в случаях, если:
- исключение не перечислено в on (средняя схема)?
- в блоке except оно повторно возбуждается raise?

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

1. В переключателе ввести икону "Вариант" с текстом "else" и соответственно обработку. Рисунок заменил.
2. Должна существовать защита с уровнем выше (внешняя), на нее будет передача управления.
В DELPHI таких флагов нет, и я не понял о чем речь и какие проблемы с принципом?

Зато в дельфи есть исключения, а в Драконе пока нет адекватного механизма их отображения.

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

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

Да. Только по правилам Дракона эта передача управления должна быть отображена соответствующим маршрутом. Переходы из любой точки на главном маршруте(внутри секции try-except), где возникло исключение - на секцию обработки. Их-то и нет на Ваших схемах, они подразумеваются. Так нельзя. На сегодня мы просто обязаны явно указывать передачу управления на Дракон-схемах.
И только потом будет "чем правее, тем хуже" - в обработчике исключения.

У Вас прямолинейная логика и требования. Но ведь:
1. Возможен компромисс - присоединить комментарий и изложить требования.
2. Есть алгоритмические примечания к иконам - поместить требования туда. В справке о их назначении, именно это говорится.
3. Укрупнить действия секции Try-Except до 1-й иконы - "Вставки". На уровне данной схемы это будет вполне логично.
4. На сегодня, язык Дракон за 20 лет вполне устоялся, существует литература, широкие массы народа ознакомились и осваивают. В ракетных делах этой проблемы нет. Нам остается принять его как данность и оставаться в его рамках.
5. Есть пример (прислали) использования языка и и.с. для создания учебного - справочного пособия в гуманитарной науке - юстиции. Там этой проблемы вообще не будет, при этом активно используются левые и правые комментарии.
6. Область действия исключения видна явно, она заключена на главном маршруте между операторами языка программирования Try-End.

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

На мой взгляд,предлагаемое Вами - не компромисс, а стратегическая ошибка. Замыливание смысла применяемых конструкций, пусть даже с разжёвыванием в комментариях, поможет разве что появлению ошибок, а не грамотному проектированию. Распространённый недостаток применения исключений - труднообнаруживаемые утечки памяти. И 20 лет с ракетной техникой на это никак не влияют.
В линейной текстовой модели практически невозможно как-то структурировать распространение исключений - зачем же тащить этот груз в Дракон-схему и обучать народ такому подходу?."Зачем самолёту махать крыльями?"

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

Вопрос: как отображать на Драконе транзакции (код, выполняемый в транзакции)? с учетом того, что невозможность зафиксировать транзакцию может быть трактована и как исключительная ситуация и как неисключительная ситуация?

Транзакция - это абстракция исполнения, основанная на использовании точек восстановления. Важно лишь одно - успешно завершена транзакция или нет, т.е. принимаем результат или откатываемся. Т.е. изобразить можно как любой линейный код, где "Begin Tran", "Commit Tran" и "Rollback Tran" - процедуры создания, удаления точек восстановления и отката(соответственно).

Что касается исключений, то в большинстве реализаций откат автоматом произойдёт только для системных исключений - тут и изображать ничего не надо, а для пользовательских - придётся откатывать вручную внутри секций catch или except. С изображением переходов на эти секции в Драконе вопрос пока не решён.

На отдельный лист их.

Ага. Исключения по сути и есть отдельное измерение - вот и пусть будет если не 3D, то просто отдельная плоскость + ссылки между плоскостями. Все попытки изобразить исключения в одной плоскости с основной логикой - противоречат самой идее исключительных ситуаций.

P.S. А вот еще есть инициализация/финализация. Обычно их хочется видеть вместе, но на схеме они получаются разнесены в пространстве и явно не обозначены. Особенно это чувствуется после использования конструкторов/деструкторов.

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

"try except" - это как механизм выглядит, а не как он работает. А Дракон, наверно, всё-таки показывает работу и старается делать это так, чтобы выглядела она удобочитаемой. "try except" - это конструкция из мира, где не требуется обязательная наглядность.

Какой?

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

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

А некорректно - можно десятком способов (я уже предлагал, и другие предлагали здесь и особенно здесь, начиная примерно отсюда).