DRAKON.SU

Кому такая схема понятнее, поднимите руки!
Хотя, конечно, пример слишком прост, чтобы делать выводы

Ошибка в схеме. Из предлагаемой нотации никак не видно, что ситуация исключения остаётся необработанной после try-finally.

Вы про if error then СделатьВсеЧтоНужноЕслиФайлаНетИлиОшибкаОбработки?

Я про то, что исключительная ситуации внутри try-finally будет обработана во внешнем try-except.
В схеме Кагена этого нет. И даже не очень понятно, как это сделать.

Да, согласен. Работа с секцией finally требует отдельного рассмотрения. В то же время, полную функциональность примера можно получить следующим образом:Можно даже ещё упростить:

Я о чём и говорю!
Плодятся процедуры, теряется визуальное единство.

Зато уходят лишние сущности - флаги ошибок, заключительная проверка и reraise(который delphi использует для реализации finally). Понятно, что finally было определённым шагом к эргономизации линейной текстовой записи программ, но идеализировать этот механизм я не стал бы. Может быть выгоднее рассматривать финализацию как работу с охранником ресурсов? Что скажут более опытные коллеги?

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

Логику этой конструкции я понимаю так (если не прав — поправьте, пожалуйста):

Выполняются инструкции между try-finally, затем между finally-end.
Если возникает ошибка внутри try-finally, то программа сразу переходит к выполнению finally-end.
Инструкции внутри finally-end выполняются в любом случае.

Для визуального изображения такой ситуации достаточно блок try-finally выделить серым квадратом и условиться что он означает.

Выполняются инструкции внутри try-except.
Если ошибки нет, то инструкции внутри except-end не выполняются.
Если ошибка есть, то выполняются инструкции внутри except-end.

Для визуального изображения такой ситуации достаточно блок try-except выделить серым квадратом и условиться что правая граница квадрата будет являться маршрутом для блока except-end. Это нужно для того, чтобы не плодить лишних ветвлений. По моему, очень эргономично : )

Таким образом получается, что просто серый прямоугольник — блок try-finally-end, а прямоугольник с иконами на правой границе — блок try-except-end.

Разные оттенки серого цвета на верхнем рисунке используются для отделения одного блока от другого и ничего дополнительно не означают.

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

C моей стороны это всего лишь попытка визуально изобразить предложенный алгоритм

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

Смотрим картинку try01.png. Не обращаем внимания, что оба обработчика показывают сообщение "Ошибка работы с файлом" и ни один - "Ошибка открытия файла".

Я вижу проблему с блоком finally. Тёмно-серый квадрат как бы намекает, что действия внутри него равнозначны, поскольку цвет фона у них идентичен. Но это далеко не так. В случае возникновения исключения в самом внутреннем блоке try, действие Закрыть файл будет выполнено в любом случае (блок finally), а действие Error := false выполнено не будет, так как после finally управление перепрыгнет в Показать "Ошибка работы с файлом" (ближайший except).

А это уже напоминает семантику оператора COME FROM языка INTERCAL.

Похожая проблема, хотя и менее заметная, есть и у картинки try01-finally.png.

Спасибо. Исправлено.

Согласен.

А вот такой вариант:

Под эргономичным инструментом Вы имеете ввиду Дзен?

Если нет, то дайте, пожалуйста, пример эргономичного инструмента.

Крест показывает, что управление уходит не в петлю силуэта, а в место прерывания.

1) Блоки except и finally представляют собой принципиально разные конструкции.
Размещение except справа от шампура оправдано и наглядно.
Finally должен размещаться на шампуре, поскольку входит в нормальный порядок выполнения.

2 Илья Ермаков: Было бы интересно увидеть нормальную (защищенную) работу с файлами БЕЗ исключений. И будет ли эта простынка наглядной?

А почему простынка. Несколько процедур, каждая какой-то результат возвращает.

Главная цепь проверок имеет вид типа:



и т.п.

Вместо вложенных IF-ELSE в таких ситуациях можно использовать цепь охран.

Несколько процедур - это разрыв маршрута, ещё хуже, чем все представленные варианты...

Почему разрыв, если обычное введение более высокоровневых понятий? Крупноблочных действий? Ну, хотите - вместо Act1...Actn пишите непосредственно действия, и выставление res.

В тексте это выглядит нормально (если без процедур). А вот в Драконе, по-моему, перегруз будет.

А в Драконе вообще проблем нет - две ситуации в итоге: успех-неуспех. С любого места главной оси в случае неуспеха прыгаем на второй путь - и вниз.