OberonCore

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

А если глубже копнуть, то увидим здесь границу процедурной идеологии программирования. В процедурах ведь как: вызвали процедуру - ждём возврата управления. Надо процедуры отменить, тогда смысл в exception пропадёт сам собой.

В том-то и дело, что быстрее...

Совершенно не против такого подхода, однако озвучу крамольную мыслю - а не является ли использование исключений палкой о двух концах? Скажем, в парадигме "исключения - это гут", обработка ошибочных ситуаций уже после старта, "на орбите", является нормальным действием. А где уверенность, что будут обработаны все ошибки? Не кроется ли тут психологический момент перекладывания проверки работы программы с этапа разработки на "потом"? Типа, у меня тут всё завёрнуто в try...except, чё беспокоиться. В таком случае, программисту надо получать допуск на использование исключений!

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

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

А где уверенность, что будут обработаны все коды ошибок? В случае исключений у меня уверенности больше просто потому, что мест для обработки нужно на порядки меньше.

А зачем вообще выводить на орбиту программу, в которой возможны ошибки? Ну, это, вопрос чисто религиозный.

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

Ошибки возможны в любой программе, даже самой надёжной. Нужна подстраховка.

Вряд ли Вам понравится, если редактор вывалится с Вашим текстом из-за исключения в подсветке синтаксиса.

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

Если сравнить код ББ, и код написанный на Delphi, то мы увидим: код ББ буквально нашпигован Assert - ми, код Delphi нашпигован , блоками try ... .
Похоже, на разные принципы. По-моему смешать не получится.

Что будет, если в Обероне вызвать процедуру, которая не возвращает значение и и именно она генерирует сбой? Таким образом, нет флажка для продолжения проверки.
Поэтому я за исключения.

Про явно тащить код ошибки - это интересное соображение! Я раньше не понимал, почему переменная sym в парсере сделана глобальной, а теперь понял! Ведь в самом деле "тащить" её через все процедуры параметром было бы громоздко. А так - вот она, переменная состояния парсера. Многопоточность реализуется элементарно: процедуры модуля делаются методами объекта, переменная sym - полем объекта. Объект работает в пределах одного потока.

Что касается контроля над чтением/изменением - достаточно всякое присвоение оформить отдельной процедурой с говорящим названием. Т.е. вместо OPS.Read вызывать всегда местный Read. Это и будут точки синхронизации и прочей обработки. Правда, убедиться в том, что не производится присвоения в неположенных местах, можно будет только вручную с помощью поиска по исходнику... Вот тут я бы подкрутил дополнительный контроль к компилятору, если придумать такой синтаксис... Например, заставить процедуры IMPORT'ировать глобальные переменные из собственного модуля (из других модулей и так импортируются через указание имени модуля, так что поиск тут работает). В том числе только для чтения. Либо квалифицировать каким-то словом (MODULE? Идентификатором модуля?). Первый вариант кажется лучше из-за возможности read-only, а второй - из-за последовательности (consistency).

Кстати, не хотите ли поупражняться ? Я предоставлю код функции на XDS Oberon-2 с использованием обработки исключений, а Вы покажете мне как обойтись без неё. В конце-концов на практических примерах и надо выяснять что нужно, а что не нужно. Может и я чего недодумал. Как на это смотрите?

В отдельную тему, пожалуй. Для желающих.

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

Мне нравиться конструкция в Delphi – try… finally.
Что бы не произошло, ну вот, просто памяти не хватило, программа выполнит завершающие операции в блоке finally.
Assert никак не сможет заменить такую конструкцию или я ошибаюсь?

Assert'ы в основном для проверки входных значений. Что будет в рантайме - не дело ББ.
У оберонщиков: проскочим опасный участок - хорошо, не проскочим - ну и ладно, имеем посмертный дамп. Пользователю от этого польза - как дырка от бублика.

Обработка исключений придумана для того, чтобы подавить аварийную ситуацию и, по возможности, вернуть вычисление в рабочее русло. А вот если проблема вылезет в секции finally, то уже никакие примочки не помогут. Так что лучше придавать себе уверенности жёсткими проверками пред- и постусловий, нежели обёртывать всё и вся в try...except. Лучше, если ошибка проявит себя как можно раньше, а не будет задавлена обработчиком исключения.

В секции finally никак проблем не может быть. Она как раз предотвращает проблемы, которые возникли благодаря случившемуся исключению. Например, отдать обратно выделенную память, закрыть дескрипторы файлов. Что-то типа сборщика мусора.
Едем дальше. Вы не можете предусмотреть ВСЕ ошибки. Одну ошибку нашли, вторая - через месяц. А третья - будет. И не факт, что последняя. Большинство возникающих ошибок - в период времени исполнения.