OberonCore

Иногда подавление ошибок - это благо.

Ну почему же сразу - не может быть? Отработка подавления аварийной ситуации тоже может содержать ошибку, которая как раз вылезет в самый интересный момент
Вы говорите - "иногда подавление ошибок - благо". Я бы добавил - всегда в особых случаях.

Ассерты у оберонщиков -- это комментарии.

Так ведь и второй помрет таким же макаром?

Ну вообще-то все с точностью до наоборот. Это в Delphi написал прямую ветку, вставил ее в try .. except, если все хорошо - проскочили, если не получилось, а нам пофиг.
А в ББ "ловишь" опасную ситуацию в Assert, а затем обрабатываешь и обрабатываешь до тех пор, пока она не перестанет быть опасной.
А вообще интересный вопрос: какая стратегия более выигрышна?

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

процедуры --> необходимо вернуть управление --> exception для отката управления (goto - для передачи управления)
ассинхронка --> управление никуда не передаётся --> переадресация сообщения ("goto" - для передачи сообщения)

Я рассматривал подобный вариант в качестве альтернативы.
IMHO, в моем случае это не лучший выход.
Действительно, многие парсеры (компиляторов) не прекращают разбор при нахождении первой ошибки, а стараются собрать и выдать побольше информации. Если вся ошибка в том, что, скажем, пропущена точка с запятой, то компилятор даже может сгенерировать правильный код (с выдачей предупреждения, конечно).
В принципе, классические компиляторы Оберона придерживаются похожей стратегии. Для работы с ошибками в модуле сканера (OSS у Вирта, DevCPM в ББ) есть процедура Mark. HALT в DevCPM вызывается только при условии trap IN options.
Но у меня разбираются простые выражения (т.е. это язык запросов), такая подробность излишня. И причин отвергнуть запрос на самом деле больше (т.к. там еще может быть уже бессмысленное обращение к таблицам). Вот я и решил "огород не городить".
Наверное, подробнее эту тему имеет смысл разбирать уже в ветке, посвященной парсерам или компиляторам.
К нашей же теме имеет отношение тот факт, что в DLL, написанной на КП, я не знаю способа прервать выполнение, аналогичного исключению или HALT. Может, и есть какой-то выход.

Выигрышна в каком смысле?

Оберон-культура ("стратегия ассертов") требует подготовки (-),
но окупается производительностью при равной надежности (+).

Еще можно пообсуждать time-to-market против client satisfaction,
но производительность (time-to-market) у подкованного программостроителя всё равно заметно выше.

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

Теперь до меня дошло.
Одно пока непонятно: как это - "и забыть про него"?
Когда мы писали ПО для системы безопасности, то, конечно, предусматривался вариант недоставки (асинхронного) сообщения по каналу связи. Но вариант "плюнуть и забыть" не рассматривался. У меня одна из программ исполняла функцию системного ретранслятора (т.е. как раз передавала сообщения от центра к абоненту и наоборот). Послав сообщение, я заводил таймер. Если таймер сработал, а я не получил подтверждения, то, в зависимости от текущего состояния, либо посылал повторное сообщение, либо отправлял центру сообщение о недоставке (такой вот аналог исключения ).

Проблем не будет, если Вы написали finally и вписали туда все освобождения.

А экскепшен может произойти в любой момент - типа той же нехватки памяти - в том месте, где вы финалли не предусмотрели. Или было лень написать. Или забыли про какой-то ресурс.

В КП память собирает сборщик мусора (100% гарантия сборки, программист ничего не пишет для этого); прочие ресурсы типа файлов закрываются в FINALIZE (программист реализует метод; вызовов не пишет; гарантия освобождения 100%).

Это всё верно.
Но остаются вопросы:

• о своевременности возврата ресурсов;
• о том, в каком месте программа реагирует на ошибку.

При чём здесь продолжение разбора после нахождения ошибки? Я предложил сымитировать получение eof. О каком продолжении разбора может идти речь после достижения конца входного потока? О каком "огороде" может идти речь, если вы в любом случае должы предусматривать достижение конца потока в каждый момент разбора?
А я не знаю столь мощного и универсального средства как goto из одной процедуры в середину цикла другой, ну и что? % )

Рассмотрим ситуацию.
Сканер вернул eot (или eof). Синтаксический разбор от этого не прекратился.
Хотя, действительно, он в конце концов "схлопнется". Так что можно было использовать eot/eof.
Ошибки в запросе у меня могут быть не только синтаксические. Конечно, можно научить сканер и в этом случае возвращать eot.
Так можно было сделать, но мне это показалось "кривым" (IMHO) и менее очевидным способом. Возможно, я и не прав.
Я предлагал нечто подобное?

В зависимости от цели: захватить рынок или решить поставленную заказчиком задачу. Есть еще проблема сроков, но это близко к задаче "захватить рынок".
Кроме того, в чисто техническом плане, есть зависимость от этапа: разработка - эксплуатация. Хотя, кажется в ББ существует возможность перенастраивать поведение при Assert, но я про это плохо знаю.

В модуле Kernel есть процедуры для перехвата исключений и установки своих обработчиков. ASSERT/HALT реализованы как выброс исключения.

Кстати межпроцедурный goto бывает реально полезен. Например при поиске в дереве.

Откуда такое противоставление "жёстких проверок пред- и постусловий" и исключений? ASSERT может быть вообще частным случаем исключения. Что касатется "всё и вся" в try/finally, то это особенность дельфи, потому что 95% finally там - это чистка памяти. В языках с GC (жаба/C#) или с возможностью автоматизированного управления памятью (C++) такого количества блоков try не требуется, за счет этого и достигается большая понятность (а значит и надежность) кода. В C++ даже finally как такового нет (потому что есть те самые деструкторы, о которых речь), так что try/catch надо еще поискать по исходникам

Противопоставление только между "проверка предусловий в ASSERT" и "попыткой продолжить вычисления с помощью структурной обработки исключений".

Тогда это опять противопоставление "реальной жизни" и идеализиолванного мира оберона Ну вот дали вам обероновский модуль, без исходников, работает хорошо, только раз в сутки у клиента он падает с ASSERT'ом с номером 123. Ваши действия? Пойдете ковырять рантайм BB? Будете пинать разработчика? Перепишите все нафиг? Вобщем все опять упирается в "если есть, то можно не использовать, а если нет, то надо придумывать велосипед". Если есть механизм исключений, то его будут использовать только для "давки" ошибок. Если есть отладчик, то его будут использовать как средство убить время. И т.д.