OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 12:48

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу 1, 2  След.

Механизм исключений в PureBuilder...
Лучше соответствует структурному программированию 25%  25%  [ 2 ]
Уменьшает количество ошибок (багов) в программе 13%  13%  [ 1 ]
Проще при чтении программы 25%  25%  [ 2 ]
Проще при отладке программы 0%  0%  [ 0 ]
Проще при кодировании программы 13%  13%  [ 1 ]
Проще для разработки транслятора 0%  0%  [ 0 ]
Быстрее при трансляции программы 0%  0%  [ 0 ]
Быстрее при исполнении программы 0%  0%  [ 0 ]
Не имеет ни одного из указанных выше преимуществ 25%  25%  [ 2 ]
Всего голосов : 8
Автор Сообщение
СообщениеДобавлено: Среда, 02 Февраль, 2011 11:13 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
:?: Оцените, пожалуйста, механизм исключений в PureBuilder по сравнению с традиционным, например, в платформе Microsoft .NET. Можно выбрать несколько вариантов ответа одновременно.

См. PureBuilder


Последний раз редактировалось Сергей Прохоренко Понедельник, 25 Апрель, 2011 11:21, всего редактировалось 9 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 13:35 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Без пункта "Ничего из перечисленного" опрос выглядит достаточно самонадеянно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 13:38 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Ильин писал(а):
Без пункта "Ничего из перечисленного" опрос выглядит достаточно самонадеянно.


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

Данный опрос - не реклама, а попытка выявить недостатки с целью устранения. Кстати, критические замечания приветствуются!


Последний раз редактировалось Сергей Прохоренко Среда, 02 Февраль, 2011 13:47, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 13:45 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Сергей Прохоренко писал(а):
Александр Ильин писал(а):
Без пункта "Ничего из перечисленного" опрос выглядит достаточно самонадеянно.
Это просто равносильно тому, что ни один из пунктов не будет выбран.
Если ничего не выбрано, форум пишет "необходимо указать вариант ответа при голосовании".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 13:13 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Не вижу вариант:
Механизм исключений не нужен [x]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 14:10 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Давайте просто новую тему с новым голосованием откроем, а эту пусть модератор сольет... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 15:06 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Мне таки удалось дополнить опрос двумя вариантами ответов:
  • Не имеет никаких преимуществ
  • В механизме исключений нет необходимости

При этом, правда, уничтожились ранее введенные ответы. :( :( :(

Прошу тех, кто проголосовал раньше, проголосовать снова.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 19:51 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Зря я поддался на уговоры дополнить варианты ответа. :(

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

Вариант "Не имеет ни одного из указанных выше преимуществ" имеет право на существование. Попытка решить проблему не всегда приводит к успеху.

Удаляю вариант ответа "Исключения вообще не нужны". :twisted:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 00:48 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Сергей Прохоренко писал(а):
Удаляю вариант ответа "Исключения вообще не нужны". :twisted:

Очень зря. Вы рискуете повторить путь С++ и угробить редактор ещё в зародыше.
С проблемой исключений я знаком очень хорошо и не могу припомнить ни одного достойного примера, когда они действительно были не заменимы, или при их применении повышалась читаемость (наглядность) кода.

Основные причины применения исключений:
* небрежность в конструировании (не думаем о некоторых ситуациях, которые потом затыкаем исключениями);
* поспешность в программировании (не желаем заморачиваться с некоторыми ситуациями и оставляем их на откуп продолжателям (например, Java));
* дань моде (очень часто видел код, где на исключениях была построена логика).

А примеры, которые приводили с драйверами устройств и т.п. смешны. Я в своё время писал достаточно много драйверов (на ассемблере) для 8086, 286, 386, 486 машин и успешно обходился без исключений, потому что для драйвера отсутствие связи с устройством - одна из штатных ситуаций, которая должна быть предусмотрена разработчиком, иначе это плохой драйвер.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 01:38 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
В С++ исключения оказались НЕОБХОДИМЫ по двум причинам: перегрузка операций (запрет дополнительных параметров), и конструкторы (не возвращают значение).
Скорее всего, в больших корпоративных системах они пригодятся. Но обработку исключений НУЖНО ПРОЕКТИРОВАТЬ, а никто этим специально не занимается. Поэтому исключения выглядят как заплата на коде.
Если исключения сделать обязательной конструкцией с привязкой к процедуре-функции, то это ЗАСТАВИТ думать, что с этим делать. Это - правильный подход.


Последний раз редактировалось Валерий Лаптев Пятница, 04 Февраль, 2011 09:44, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 02:38 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Я бы вместо механизма исклений ввёл на уровень языка тип возвращаемого функцией значения ErrorFlag. Если программист игнорирует возвращаемое значение такой функции, то есть использует её как процедуру, то компилятор сам дописывает аналог обработчика с аварийным завершением.

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

1) Вариант, когда программист считает, что результат должен быть всегда положительным.
NEW(A);

Результат компиляции:
IF ~NEW(A) THEN ASSERT(FALSE) END;

2) Вариант, когда программист выделяет большой объём памяти, размер которой задаётся внешними факторами (например, размеров считываемого в память файла):

IF NEW(A) THEN
...
ELSE
...
END;

Поскольку результат функции не был проигнорирован, дополнительного кода компилятор не создаёт.

Данный подход позволяет полностью избавиться от необходимости механизма исключений в подобных функциях. Пример математической функции:
FUNCTION Divide (A, B: INTEGER; OUT Res: INTEGER): ErrorFlag;

...
Divide(A, B, C); // если B = 0, то программа аварийно завершится из-за деления на нуль
...
IF Divide(A, B, C) THEN // программист определяет логику обработки
...
END;

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 09:47 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Интересно. Та же мысль: в языке ПРИНУДИТЕЛЬНО требуется обработка ошибок - проигнорировать нельзя. Но решение мне кажется слишком радикальным. Все же синус, например, должен возвращать синус, а не ErrorFlag.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 10:16 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
Интересно. Та же мысль: в языке ПРИНУДИТЕЛЬНО требуется обработка ошибок - проигнорировать нельзя. Но решение мне кажется слишком радикальным. Все же синус, например, должен возвращать синус, а не ErrorFlag.


Мне ErrorFlag кажется, наоборот, излишне компромиссным решением - попыткой минимизировать изменения синтаксиса. При создании по сути нового языка для семантического/структурного редактора разработчики могут себе позволить сделать полноценные выразительные конструкции, а не довольствоваться паллиативными решениями. Но для "тюнинга" существующего языка это неплохой вариант для процедур, не возвращающих значение. Для функций, возвращающих значение, он, действительно, неудобен - выражения будут очень громоздкими и нечитабельными.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 13:11 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Валерий Лаптев писал(а):
В С++ исключения оказались НЕОБХОДИМЫ по двум причинам: перегрузка операций (запрет дополнительных параметров), и конструкторы (не возвращают значение).
Скорее всего, в больших корпоративных системах они пригодятся. Но обработку исключений НУЖНО ПРОЕКТИРОВАТЬ, а никто этим специально не занимается. Поэтому исключения выглядят как заплата на коде.
Если исключения сделать обязательной конструкцией с привязкой к процедуре-функции, то это ЗАСТАВИТ думать, что с этим делать. Это - правильный подход.

Если убрать механизм исключений из языка, то это ЗАСТАВИТ ДУМАТЬ ещё сильнее, и проектировать код более правильно.

На самом деле в конструкторах можно обойтись без исключений. Вот с перегрузкой операторов - несколько сложнее, но впринципе - тоже можно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 17:23 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Для функций, возвращающих значение, он, действительно, неудобен - выражения будут очень громоздкими и нечитабельными.

Если функция не в состоянии гарантированно вернуть результат, то результат нужно возвращать через дополнительный параметр, а возвращаемое значение - флаг ошибки. Иначе у нас только два выхода:
1) Перегрузка результата. Самый худший из способов. Считать что <0, -1, -2, 2^32-1, 0, '' или как в динамических языках false/null - это ошибка, а остальные значения - ок. В чём проблема? Во-первых, мешается информация с метаинформацией (значение и флаг ошибки в одном параметре). Во-вторых, проверять всё равно нужно. А если не проверять, ради "удобства" и "читаемости", то в отличие от FlagError с незамедлительным остановом мы получаем ошибочное поведение. Наконец, обилие типов подобной метаинформации обычно зашкаливает и провоцирует на ошибки.
2) Бросание исключения любой функцией, чей результат не гарантирован.

Если применять исключения в виде catch, неясно, что будет в следующей ситуации:
C:=sin(a) + sin(b);
catch ... // А что ловим? Проблема в "a" или в "b"?

Это раз. Во-вторых, теряется возможность на основе логического результата писать цепочки функций:
IF NOT (OpenFile(...) AND ReadWholeFile(...) AND (FileSize > 0)) THEN
...
ELSE
...
END;

Логические выражения с функциями, основанными на булевом результате записываются и комбинируются легко при помощи OR, AND, NOT. В случае исключений всё гораздо хуже. Нужно ставить обработчики часто и усложнять код для поддержки выходов из середины функций.

Исключения в таком виде эмулируют следующую конструкцию: Res:=A AND B AND C;
Иными словами, в блок обработки исключений попадаем, если хотя бы одна функция из цепочки сгенерировала исключение. А вот более сложные условия - увы.

Предположим, что две функции с негарантированным результатом используют исключения для сигналов ошибки. Как написать следующее выражение: Found:=FindOnLocalPC(...) OR FindOnServer(...) в стиле обработки исключений?

Код:
Found:=FALSE;
TRY
  Res:=FindOnLocalPC;
  Found:=TRUE;
EXCEPT
END;
IF NOT Found THEN
  TRY
    Res:=FindOnServer;
    Found:=TRUE;
  EXCEPT
  END;
END;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Февраль, 2011 14:09 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Шостак писал(а):
Если применять исключения в виде catch, неясно, что будет в следующей ситуации:
C:=sin(a) + sin(b);
catch ... // А что ловим? Проблема в "a" или в "b"?


Если уж нужна такая точность (в чем я сомневаюсь):
C:=sin(a);
catch
C:=C + sin(b);
catch

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

Александр Шостак писал(а):
Это раз. Во-вторых, теряется возможность на основе логического результата писать цепочки функций:
IF NOT (OpenFile(...) AND ReadWholeFile(...) AND (FileSize > 0)) THEN


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Февраль, 2011 15:17 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Если уж нужна такая точность (в чем я сомневаюсь):

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

Цитата:
Во-первых, в реальной жизни они не нужны.

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

Код:
RESULT   :=
      ValidateMinStructSize AND
      ValidateSignatureField AND
      ValidateStructSizeField AND
      ValidateBodyCrc32Field;

RESULT   :=
      (NewLanguage = Client.LangName) OR
      LoadClientLangFromResPack (Client, NewLanguage) OR
      LoadClientLangFromFilePack (Client, NewLanguage) OR
      LoadClientLangFromFileUnit (Client, NewLanguage) OR
      LoadClientLangFromFileStrArr (Client, NewLanguage);


Vlad говорит, что в больших объёмах кода с использованием исключений достаточно десятка обработчиков. Мне кажется, что это либо очень общие обработчики верхнего уровня (а что там уже можно сделать?), либо на реальные ошибки просто забили. Обычно нужно видеть код, чтобы судить достоверно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 01:00 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Шостак писал(а):
Цитата:
Если уж нужна такая точность (в чем я сомневаюсь):

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


Поясню свою мысль. Экзотика, когда в выражении несколько раз встречается одна и та же функция (у Вас хорошая фантазия :D ), обрабатывается указанным выше способом. Если функции разные, то и исключения, и обработчики будут разными. Проблема решена.

Но самое главное, что возможность во время исполнения точно распознать причину действительно серьезного исключения как правило не важна! Исключение в PureBuilder завершает аварийную процедуру/функцию без возврата скомпрометированных данных в вызывающую процедуру/функцию, и этого более чем достаточно. И не столь уж важно, почему возникло исключение. Если процедура/функция дала сбой, то полагаться на нее уже нельзя - независимо от причин. Нужно искать другие выходы.

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


Александр Шостак писал(а):
Цитата:
Во-первых, в реальной жизни они не нужны.

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


В PureBuilder если процедура/функция вернула параметры/возвращаемое значение в точку вызова, значит она завершилась без исключений. В этом случае нет никакой необходимости в флагах, проверках, длинных цепочках логических операций и т.п. Всё и так OK.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 02:16 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Это не штатный алгоритм, в котором важны детали - для дальнейшей обработки. Нынешняя практика, к сожалению, такова, что исключения используются для штатного алгоритма, и программисты поэтому требуют знания точной причины исключения. При действительно аварийной ситуации надо просто срочно спасать программу с минимальными потерями, а не разбираться с причинами.

Цитата:
В PureBuilder если процедура/функция вернула параметры/возвращаемое значение в точку вызова, значит она завершилась без исключений.

Функция StrPos поиска подстроки в строке должна возвращать найденную позицию. Но она может и не найти подстроки. Как в вашем случае она вернёт результат? И вообще как быть с обычными функциями, чей результат не гарантирован? Например, чтение сокета. Должно возвращать строку, а тут ошибка. Исключение?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Февраль, 2011 18:50 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Шостак писал(а):
Функция StrPos поиска подстроки в строке должна возвращать найденную позицию. Но она может и не найти подстроки. Как в вашем случае она вернёт результат? И вообще как быть с обычными функциями, чей результат не гарантирован? Например, чтение сокета. Должно возвращать строку, а тут ошибка. Исключение?

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB