DRAKON.SU

А-а... гм... да... ну да...

Может так:

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

Не, народ, так не пойдёт. Можно ещё начать писать {$I+},{$I-}, проверять IOResult.. Потом для них придумать иконки .

Можно вообще не обращать внимания на исключения. Но прерывания-то останутся. А в основе этих сущностей лежит всё тот же структурный переход. Различия только в семантике окончания. И возможных вариантов всего 3. Легко узнать где-что:
1. отменить
2. продолжить
3. перезапустить

Именно эти варианты имеют право на жизнь в Драконе. Разве это не полный контроль?

Что значит - так не пойдёт?!

Сколько можно говорить об одном и том же - механизмы исключений и прерываний - принципиально разные механизмы!

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

Место возникновения "исключений" однозначно определено алгоритмически, и конструкция эта в основном введена из-за лени программистов.

Прерывания - это внешние воздействия на программу, заранее непредсказуемые!

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

Да, да. Вот только "деление на ноль" специально завернули на внутренние прерывания, дабы ни у кого не возникло даже и помыслов о лени .

Исключения могут возникнуть и при сложении двух действительных.
НЕ ПРОВЕРЯТЬ каждое такое сложение (с возвратом некого результата через хрен его знает сколько процедурных вызовов) - это вовсе не лень. Это желание заниматься делом, опираясь на аппаратную поддержку этих проверок.
Чего-то мне именно так кажется

Вопрос дискуссионный. Вы б ещё погрешность вычисления так оценивали - "методом исключения"

Вот подозреваю я, что разницы между исключением плавающей арифметики и исключением при работе с файлами нет никакой:
- в обоих случаях имеет место единый цельный участок программы, который можно рассматривать как программную единицу (формула и какая-нибудь инициализация структуры данными из файла);
- в обоих случаях имеется внешнее устройство (FPU или файловое устройство), которое может выполнить запрос с ошибкой;
- в обоих случаях реакция на исключение одинакова (инициализация внешнего устройства, приведение структур данных в корректное состояние с учётом обработанной ошибки).

Почему же во втором случае считаем (по крайней мере, мы с Ильёй) целесообразным явную проверку результатов всех запросов; а в первом случае мы хотим "аппаратную поддержку" и "заниматься делом"?
Вот кто объяснит такое противоречие?

Я вижу единственное разумное объяснение - второй случай гораздо сложнее . Достаточное ли это объяснение?!
Другая сторона этого объяснения - первый случай слишком прост (почти вырожден). Сопроцессор элементарно привести в исходное состояние. Результат вычисления формулы либо получен, либо нет.

Ваши соображения?

касательно семантики окончания при обработке исключений есть неплохой разбор pro-et-contra у Страуструпа в "Дизайн и эволюция языка C++"(Москва, ДМК Пресс, 2006) - c.395

Ещё более интересен вывод, что потратив 2 года на споры, у него возникло впечатление, что можно привести убедительные логические доводы в пользу любого из вариантов . Страуструп признал, что в этом вопросе народ "оказался в положении всё тех же античных философов, которые так яростно и умно спорили о природе вселенной, что как-то забыли о её изучении".
Разница только в том, что там шла речь о том, какую конкретную реализацию семантики включить в язык, а у нас, применительно к Дракону, идёт речь о предоставлении доступа к более общему механизму - структурному переходу.

Потому-что Вы с Ильей не правы
Но к Дракону это особого отношения не имеет.
Логика обратная: сначала понимаем нужно это или нет, на чего это влияет и как, а вот уже потом - как это представляется в некой среде.

Если "плохо" представляется - это не повод объявлять сие ересью. Вот "у меня" - хорошо представляется. В смысле - визуализируется (если помните).

Если есть возможность, дайте, пожалуйста, ссылку.

Да используется оно, используется... Только очень крупноблочно (на уровне обработки отказов в целых блоках и восстановлении на этом уровне). А это уровень системщика - ну, например, того, кто формирует серверное приложение. А не прикладника, который пишет логику внутри каждого модуля. Ему этот try лучше не давать.

Вот ещё такой вариант:

Мои варианты:

Последние варианты Ильченко Эдуарда и adva, по моему, вносят двойную избыточность:

по шапуру на секции try и except для единственного шампура, представляющего задачу.

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

Позже постараюсь перерисовать схему от Olegar в силуэт.

Спасибо. Будем с интересом ждать.

Силуэт размещён в теме от Olegar