OberonCore

Валерий Лаптев высказывался в пользу механизма исключений для семантического редактора. И действительно, бывают ситуации (машинные сбои, некорректная работа чужих модулей и т.п.), когда механизм исключений необходим (см. библиотечные процедуры Kernel.Try в Блэкбоксе). С другой стороны, его неограниченное использование нарушает парадигму структурного программирования. Но особенности PureBuilder возможно позволят купировать этот недостаток и использовать механизм исключений всегда, когда это необходимо для обеспечения надежности (не для конструирования алгоритма!).

В этой теме предполагается обсудить возможную модификацию механизма исключений с учетом особенностей PureBuilder:

1) В PureBuilder программа не представляется в виде единого текста, а состоит из объектов (подсистем, модулей, функций и процедур, выражений и т.д.), отображаемых в отдельных окнах. Все элементы такого объекта программы (для процедур - входные и выходные параметры и локальные переменные) специфицируются стандартным и подробным образом в специальных таблицах интерфейса. Синтаксис механизма исключений в PureBuilder может кардинальным образом отличаться от обычного, например, могут использоваться таблицы элементов или их параметров. Следовательно, можно перехват исключений привязать непосредственно к месту их возможного возникновения, и можно явно и принудительно ограничить случаи, когда программист может использовать механизм исключений. Такие ограничения сейчас устанавливаются корпоративным стилем программирования.

2) В интерфейсе PureBuilder можно предусмотреть место для перехвата и обработки кодов ошибок, возвращаемых функциями и процедурами. Такие коды ошибок в необходимых случаях могут стать обязательными.

3) PureBuilder нет границы между языком и стандартной библиотекой.

4) В PureBuilder имеется среда времени исполнения, на которую можно возложить обработку исключений.

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

Если о визуальной составляющей синтаксиса - то это могло бы выглядеть как оператор 35Д здесь.

Наверное, да...

Что-то как-то очень вяло народ реагирует. Я, наверное, слишком взвешенно и политкорректно тут выразился. Все внутренне согласились и зевнули. Надо, наверное, было что-нибудь провокационное загнуть - на грани удаления в архив. Типа "исключения рулят форева!, будем применять направо и налево!". Я давно заметил, что самые оживленные дискуссии инициируются "несистемной оппозицией" (а потом удаляются в "Опять двадцать пять" ). Когда все просыпаются, может и что-нибудь полезное проклюнуться.

Мой личный опыт использования исключений равен нулю. Только в молодости, программируя на PL/I, я мечтал о таком механизме (о ужас!) для построения алгоритма. Тогда мне еще не было известно, к чему такое приводит.

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

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

2. Аппарат исключений не плох сам по себе - это просто средство. Плохо его бесконтрольное использование.
Более того, от аппарата исключений начинающий ждет автоматической работы и перехвата всякого рода аварий. Студням приходится разъяснять, что обработку исключений нужно планировать самому.
Кстати, в PL-1 был оператор ON. Я помнится небольшую прогу на основн него слабал... Тогда возникло ощущение - плохоуправляемый код.

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

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


BTW: Де-жа-вю какое-то... Где-то я уже писал, кажется, и про "зачем", и про "как рисовать"...

Но Вы ведь хотите внести механизм исключений в семантический редактор! Может быть, пока повременить - покуда всё не прояснилось?


Я тоже помню такой оператор, но нам его не рекомендовали, поэтому я не использовал.

Спасибо! Но как это всё формализовать и засунуть в семантический редактор - непонятно. Наверное, сказывается отсутствие у меня опыта.

Моя позиция - обработка исключений в том виде, в котором она применяется в мейнстриме, вредна. Нарушается структурность и формальные свойства блоков. Подобный прыжок (исключение) несёт в себе свойства goto, просто адреса возвратов хранятся в динамическом стёке. Исключения нужны в двух случаях: когда программа падает, чтобы успеть совершить перед смертью определённые действия, и когда экранируются атомарные операции, которые могут вызывать исключения и программист хочет их учитывать. К таким операциям относятся прежде всего арифметические, а также работа с сопроцессором. Для всего остального есть результат функции, есть OUT-параметры и иные способы сообщить об ошибке.

Согласен с предыдущим оратором...
У меня сложилось мнение, что исключения в С++ появились как результат перегрузки операций и наличие конструкторов.
Ибо при перегрузке операций никаких дополнительных параметров задавать нельзя. И конструкторы тоже не возвращают значений. А дополнительный параметр в конструкторе - это тоже не фонтан, хотя и можно. Прикиньте, при объявлении и инициализации объекта типа комплексное число помимо мнимой и действительной части надо задавать еще и параметр для индикации возможной ошибки. Это сразу нарушает главный принцип: новый тип данных не должен отличаться от встроенных.
Я согласен, что аппарат исключения в С++ - не фонтан. Но это - явный аппарат обработки ошибок, который в тексте программы БРОСАЕТСЯ в глаза. В отличие от кодов ошибок. А это - важное свойство.
С другой стороны, во всех промышленных языках такой аппарат есть. Знакомить с ним надо. В общем - тут у меня большие сомнения.

Да, соглашусь.

По практике использования - ну, разумеется, в ПО 24*365 (серверном, в частности) не обойтись без этого. В определённых местах - на главных циклах приложения, ну и всякие операции, в которых куча порогов "успех-неуспех" по многим уровням вызова рассредоточена (т.е. работает последовательность многих процедур, и в каждый момент может, например, соединение нагнуться) часто хорошо писать с ASSERT-ами на успех, а потом исключение от ASSERT-а перехватить на верхнем уровне, инициировавшем операцию.
Использую окультуренную обёртку над Kernel.Try, которая в качестве параметра вызываемой процедуре передаёт ANYREC.

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

Есть другой вариант, который мне нравится гораздо больше: разработать принципиально новый механизм явного контроля ошибок, основываясь на (чужом) опыте правильного применения исключений, ASSERT'ов, кодов ошибок и на тех новых возможностях, которые дает структурный/семантический редактор. Я попытаюсь набросать первый драфт концепции и выложу тут для обсуждения и улучшения. Хотя такого нового механизма нет в других языках программирования, но его можно худо-бедно "эмулировать" имеющимися средствами - у студентов появится понимание, к чему надо стремиться, выработается правильный стиль.

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

Не вообще, а только в С++. В python'e и java у них исключения используются вовсю.
Также в Ada исключения чудо как хороши.

Ну, в Яве они просто принудительно заставили везде их использовать...
Хорошо бы познакомиться, что сделано в Аде.

Что значит заставили? Не нравится, не ешь. Т.е. стандартные исключения из стандартных библиотек лови на самом низком уровне а дальше как обычно. В общем то в С++ то же самое.

Но гугл же ещё и свои исключения в яве использует. Т.е. этим механизмом активно пользуется. Не гнушается.

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

Не использовать свои исключения -- легко. И не использовать исключения в массе своего кода -- тоже легко. Я даже написал как. Более того, так обычно и делают. На тех же плюсах. У нас например.

Если каркас основан на них - уже нелегко. И если половина модулей с ними - тоже не легко. А к ограниченной части АПИ, конечно, можно написать переходники без исключений.

Ну какой нафиг каркас? Гугл использует в основном самое базовое явовское.