OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 27 Май, 2018 06:10

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




Начать новую тему Ответить на тему  [ Сообщений: 96 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 01 Август, 2017 14:32 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 622
Откуда: Киев
Kemet писал(а):
Это не генерация исключения, это исключение.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 14:33 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2082
Откуда: Красноярск
Интересная дискуссия. Размышлял об это тоже. В готовой программе и при отладке программы обработка ASSERT аварийных остановок/исключений должна выполнятся по разному. Сам Блэкбокс, например, не останавливает всю программу при срабатывании ASSERT, а только процедуру, и запускается Kernel.TrapHandler.

Есть возможность установить собственный обработчик аварийной ситуации, и это может быть сбор отчета и отправка его по почте, или запись в какой-то журнал ошибок, или запуск какой-то аварийной программы, которая начнет проверку всех подсистем и в случае неисправности в железе, осуществит экстренную посадку самолета на автопилоте.
Код:
   PROCEDURE InstallTrapViewer* (h: Handler);
   BEGIN
      trapViewer := h
   END InstallTrapViewer;

   PROCEDURE InstallTrapChecker* (h: Handler);
   BEGIN
      trapChecker := h
   END InstallTrapChecker;


В фреймворке Micro для микроконтроллеров у Александра Ширеяева тоже интересно сделано. Я писал заметку http://obertone.ru/ob/o7/debug
При срабатывании ASSERT контроллер перезапускает программу, но в памяти хранится отчет об ошибке, и возможно после перезапуска запустить алгоритм обработки этого отчета, включая отправку отчета на ПК предусмотренным каналом связи. Очень удобная штука, я активно пользуюсь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 14:59 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 460
Иван Денисов писал(а):
...

Так и делают.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 15:03 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 460
Comdiv писал(а):
Kemet писал(а):
Это не генерация исключения, это исключение.

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

Отчего-же? Это разные термины.
Так и вырубается. Только программа. А если ошибка в системе? Может и система вырубится - Синий Экран Смерти никуда не делся, просто стал красивше, видимо дизайнеры поработали, чтобы пользователь не так грустил взирая на это чудо. а вот сегодня у меня линукс грохнулся. Ну тут всё печально и не так красиво - чёрный квадрат малевича.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 15:39 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 622
Откуда: Киев
От того, видимо, что у Вас другие термины, потому и жонглирование.
Kemet писал(а):
Так и вырубается. Только программа
О том и речь, что только программа. Система оперирует изолированными программами, и при возникнувшем исключении не грохается пользователю на голову, а позволяет восстановиться и работать дальше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 20:24 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 460
Comdiv писал(а):
О том и речь, что только программа. Система оперирует изолированными программами, и при возникнувшем исключении не грохается пользователю на голову, а позволяет восстановиться и работать дальше.

Так не восстанавливает же! Ну нельзя же назвать восстановлением тыкание мышкой по ярлыку для запуска программы. Или нажатие кнопки reset для перезагрузки. Действительно, какие-то у нас разные представления местами проскакивают


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 21:34 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1064
Откуда: СССР v2.0 rc 1
Если делать по Вирту, то контроль инварианта будет отловлен на этапе его возникновения. Если сделано из рук вон плохо -- то уровнем выше.

Кемет старательно всех запутывает, за что ему большое спасибо.
ASSERT -- это СТРУКТУРНОЕ предусмотренное прерывание. Потери контроля -- не происходит.
INT 21h -- это ПРОГРАММНОЕ предусмотренное прерывание и тоже потери контроля -- не происходит.
А trap: -- это глупость! Вот тут -- действительно потеря контроля. Что случилось? Где случилось? Почему случилось? Ответа нет...)

И ещё одно путает Кемет.
1. Есть этап проработки.
2. Есть этап опытной эксплуатации.
3. Есть этап промышленной эксплуатации.

Если в промышленную эксплуатации принимается ПО, где по результатам опытной эксплуатации в выводах комиссии написано "непонятно почему вылетает иногда по трапу, но так ничо" -- это означает -- хреновая модель данных -> хреновый алгоритм обработки данных -> хреновая архитектура -> Ура! Модно! Мейнстрим!

Если же заключение комиссии было положительным, и во время полёта самолёта вылез ASSERT -- экипаж продиктует данные специалисту, что-то можно будет понять. И таки это повысит надёжность для всех. А если вылезет exception (или ещё хуже вообще вылезет что попало и где попало) -- про это мы уже никогда не узнаем. Будет очередная ошибка пилотов)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Август, 2017 23:06 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 622
Откуда: Киев
Kemet писал(а):
Так не восстанавливает же! Ну нельзя же назвать восстановлением тыкание мышкой по ярлыку для запуска программы.
Это ровно то, что требуется для интерактивной системы. Форма восстановления контроля, совершенно внезапно, полностью зависит от того, какая задача выполняется. А у нас с Вами не столько понимание разное, сколько цели в беседе отличаются, насколько я могу судить.


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 460
Comdiv писал(а):
От того, видимо, что у Вас другие термины, потому и жонглирование.
Так они не у меня другие. У меня-то как раз общепринятые:
1) Исключительная ситуация( исключение ) - это когда дальнейшие выполнение некоего алгоритма невозможно или бессмысленно.
2) Генерация исключений - это информирование системы о возникшем исключении. Например, используя ASSERT, HALT, throw, raise ...).
3) Обработка исключений
Кроме того, нужно различать аппаратные и программные исключения.


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 460
prospero78 писал(а):
Если делать по Вирту, то контроль инварианта будет отловлен на этапе его возникновения.

Я извиняюсь, но "по Вирту" это как?
prospero78 писал(а):
И ещё одно путает Кемет.
1. Есть этап проработки.
2. Есть этап опытной эксплуатации.
3. Есть этап промышленной эксплуатации.

Я путаю??? Забавно. Я же написал:
Kemet писал(а):
Как реагировать на исключительную ситуацию, как её обрабатывать зависит от многих факторов, то есть от контекста - от назначения программы, от этапа разработки, от места использования и тп.


Цитата:
Если в промышленную эксплуатации принимается ПО, где по результатам опытной эксплуатации в выводах комиссии написано "непонятно почему вылетает иногда по трапу, но так ничо" -- это означает -- хреновая модель данных -> хреновый алгоритм обработки данных -> хреновая архитектура -> Ура! Модно! Мейнстрим!
Это всего лишь означает, что комиссия хреновая.


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 622
Откуда: Киев
Kemet писал(а):
Comdiv писал(а):
От того, видимо, что у Вас другие термины, потому и жонглирование.
Так они не у меня другие. У меня-то как раз общепринятые:
1) Исключительная ситуация( исключение ) - это когда дальнейшие выполнение некоего алгоритма невозможно или бессмысленно.
2) Генерация исключений - это информирование системы о возникшем исключении. Например, используя ASSERT, HALT, throw, raise ...).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Август, 2017 20:45 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Любопытная тема ожила. Актуальность не утрачена, несмотря на старт в 2009 г.

GeoVit писал(а):
ПРИМЕР ВОПИЮЩИЙ!!!
"Правильные" слова:
Madzi писал(а):
Появились исключения не от хорошей жизни, а от упавшего уровня программистов разработчиков, которые вместо грамотного построения программы "ловят" ошибки на выходе.

И ярчайшее подтверждение:
Madzi писал(а):
Пример 1:
try {
a = x / y;
} catch (Exception e) {
System.out.writeln("Деление на нуль.");
}
Пример 2:
IF x = 0
THEN Out.String("Делитель(??????)равен нулю"); Out.Ln;
ELSE a = x / y;
END;

АПЛОДИРУЮ СТОЯ!!!


В примере, видимо, есть опечатка: проверять необходимо "y" (делитель). Но возможно и нет, я не отслеживал весь контекст истоков первоначального сообщения, взято отсюда:
viewtopic.php?f=6&t=1454&sid=1ac07916d41e14df369b44ef0ba0b688#p27247

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

Alexey_Donskoy писал(а):
Давайте уж сравнивать сравнимые вещи. Например:

Вариант 1: try a:=x/y except a:=inf end;
Вариант 2: if abs(y)>=eps then a:=x/y else a:=inf;

Или же:
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(y)>=eps then a:=x/y;

По-моему, так эти варианты ничего по существу не доказывают. Их использование зависит от задачи. Удобство не сильно отличается. Затраты, в общем, тоже не сильно.


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


GeoVit писал(а):
Алексей, не увиливайте!

А если Ваши примеры напишут вот так:

Вариант 1: try a:=x/y except a:=inf end;
Вариант 2: if abs(x)>=eps then a:=x/y else a:=inf;

Или же:
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(x)>=eps then a:=x/y;

Какой вариант будет безопаснее в эксплуатации, а?


Alexey_Donskoy писал(а):
GeoVit писал(а):
Вариант 1: try a:=x/y except {значение а не изменяется} end;
Вариант 2: if abs(x)>=eps then a:=x/y;
Какой вариант будет безопаснее в эксплуатации, а?
То, о чём Вы говорите, называется скрытой ошибкой, которая закрывается "мягкой подушкой" исключения, но в ран-тайме. Такая практика, к сожалению, имеет место, но я бы назвал её категорически недопустимой! Потому что никто заранее не скажет, какие побочные эффекты может иметь сокрытие такой опечатки.
Поэтому второй вариант предпочтительней. Он навернётся сразу.


В общем, в целом здесь основные недостатки механизма исключений. И один из факторов деградации IT-отрасли.

Однако, такова позиция в меньшей степени применима к таким языкам как С++, где широкий пласт "низкоуровневых" исключений аля "Segmentation Fault" не отлавливается блоками try/catch. Сигналы SEGFAULT и т.п. заполучить можно для технических нужд (фиксация проблем и т.д., с помощью "неструктурной обработки исключений"), а MS-компиляторы смогут и через try, но это не стандарт и не кроссплатформенно и не поощряется. Прежде всего, декларируется политика аварийного останова процесса, т.к. выявлено "неопределенное поведение" и в общем случае некорректное состояние программы. Как и политика "assert"-ов в Обероне (если я правильно понимаю не используемый мной инструмент). Пусть это явление будет "паникой" (поскольку здесь выше есть дискуссия о терминах, и я воспользуюсь тем, что вошло в обиход мейнстрима благодаря Go, Rust для отличения "классического" механизма исключений). Проверку многих предусловий в С++ игнорировать проблематично на фоне иных популярных языков с исключениями.
Отсюда, исключения в аля С++ не отменяют потребности (если такова имеется) для реализации мониторов процессов (в дополнение к прикладным, между которыми организуется некий IPC и реализуется политика перезагрузок. Возможна ограниченная runtime-среда и внутри одного процесса и т.п.).

И, согласно популярным представлениям, альтернатива механизму исключений для анализа постусловий или результатов операций есть применение явных проверок кодов возврата или глобальных флагов. Задача не простая, и эта тема форума также косвенно возникла из-за методов её решения. Здесь были и "профильные" темы аля (со ссылками там на смежные):
viewtopic.php?f=27&t=3175

Вспоминаются и "семантические редакторы", когда-то активно обсуждаемые на форуме, как проект PureBuilder, где имеется конструкция "progress" и др.:
https://sites.google.com/site/purebuilder/

В языке Go ввели кортеж в качестве результата функции, видимо, не в последнюю очередь, чтобы коды ошибок явно наглядно торчали как lvalue.
В общем, допускаем, что обработка кодов результата операций алгоритмически разрешима в том или ином виде. Однако, у "классической" техники "коды ошибок" есть существенный недостаток на фоне механизма исключений -- исключения игнорировать невозможно. Ни компилятор, ни runtime-среда не могут дать гарантии, что все необходимые проверки кодов возврата выполнены. Если есть возможность где-то что-то упустить, то такая возможность обязательно реализуется.

Ещё одна альтернатива -- результат операций упаковывать в контейнер, к примеру, в виде алгебраических типов данных, и компилятор в этом случае вынуждает их оттуда "доставать". Такой подход применяют в Rust:
https://doc.rust-lang.org/book/second-e ... dling.html

с использованием универсальных комбинаторов аля unwrap, expect, или есть возможность организовать средства под конкретную задачу. Но главная фишка там среди универсальных механизмов -- реализация парадигмы досрочного выхода и "проталкивания" результатов "наверх" -- см. оператор "?". Здесь подробнее:
https://github.com/glaebhoerl/rfcs/blob ... andling.md

где оценивается задумка внедрения в т.ч. и конструкции try..catch, и других сопутствующих расширений. Фактически, в Rust реализуются монады, но с использованием "синтаксического сахара" (как аля внедрение do-нотации в функциональных языках). Причём в таком случае политика "checked exceptions" (которая провалилась в Java, например) здесь реализуется естественным образом в соответствие с системой типов языка.

Есть ещё один момент на фоне обычных исключений. После обработки исключения в секции catch (except) возможно продолжение кода, где м.б. использованы объекты, состояние которых изменялось в секции try. Т.е. обработка исключительной ситуации должна учитывать возможность доступа к состоянию, модификация которого была прервана. В случае же монадического подхода продвинуться по монаде без анализа результатов предшествующих операций невозможно (там, где эти результаты востребованы), в т.ч. секция "catch" в Rust также всегда возвращает результат. Это конечно же не алгоритмические гарантии, а всего лишь палочка у компилятора, с помощью которой он может лишний раз стукнуть по башке разработчику. Что полезно.

Таким образом, в Rust реализуется политика, близкая к С++. Имеются "паники", которые могут возникнуть где угодно (к тому же они принуждают не лениться и не забывать об инвариантах с проверками). В т.ч. ими вынуждены пользоваться в тех случаях, когда невозможно явно сообщать свой результат (например, в реализации инфиксных операторов, "конструкторов" данных и пр.). И "псевдоисключения" для анализа результатов операций.

Реализация "монад" в Rust пока хромает. К примеру:

enum MyError {}
fn f() -> Result<i32, MyError> { Result::Ok(1) }
fn main() { f(); }

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Август, 2017 20:54 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Madzi писал(а):
Рассмотрим Википедию http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%B8%D1%81%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B9
Цитата:
...
Недостаток исключений — в том, что их поддержка снижает скорость работы программы. Поэтому в местах программы, критичных по скорости, не рекомендуют возбуждать и обрабатывать исключения, хотя следует отметить, что в реальности такие случаи крайне редки, во всяком случае, в прикладном программировании.

Также в сложных программах возникают большие «нагромождения» операторов try ... finally и try ... catch (try ... except).

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


В современных компиляторах обработка исключений может быть реализована относительно эффективно. Некоторые положения по этому поводу:
https://habrahabr.ru/post/279111/
https://habrahabr.ru/post/208006/
https://habrahabr.ru/post/267771/

И про SEH до кучи:
http://qxov.narod.ru/articles/seh/seh.html

Причём какие-то внутренние механизмы исключений не помешают и для монадического подхода (возможно менее затратном, чем классические исключения), о котором речь выше. Также и для раскрутки стека при "паниках".

Насчёт сопутствующего "finally". Практика в отрасли показывает, что рядом с исключениями крайне желателен некоторый механизм аля RAII в С++, defer в Go, или scope(...) в D:
http://dlang.org/exception-safe.html

scope-механизм видится очень таки соблазнительным для дополнения монадического подхода обработки ошибок.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Август, 2017 20:58 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Madzi писал(а):
Цитата:
Достоинства использования исключений особенно заметно проявляется при разработке библиотек процедур и программных компонентов, ориентированных на массовое использование. В таких случаях разработчик часто не знает, как именно должна обрабатываться исключительная ситуация (при написании универсальной процедуры чтения из файла невозможно заранее предусмотреть реакцию на ошибку, так как эта реакция зависит от использующей процедуру программы), но ему это и не нужно — достаточно сгенерировать исключение, обработчик которого предоставляется реализовать пользователю компонента или процедуры. Единственная альтернатива исключениям в таких случаях — возврат кодов ошибок, которые вынужденно передаются по цепочке между несколькими уровнями программы, пока не доберутся до места обработки, загромождая код и снижая его понятность.

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

Итак, достоинство:
1. В том, что вместо того, чтобы обработать ошибку на месте программист (ссылаясь на незнание мотивов другого программиста) перекладывает обработку на плечи "потомка" (отмазка). (При этом ссылаются на процедуру чтения из файла. Всё что нужно знать при чтении из файла, так это прочитаны данные - всё хорошо, или не прочитаны - есть ошибка. Можно, конечно, используя код ошибки передавать причину неудачи: отсутствует файл, занят другим ресурсом и т.п., но как правило для родительской программы это не важно).
2. Безусловно, читаемость кода возрастает, поскольку сразу виден опасный участок и его обработка, но это преимущество сомнительное, так как если есть проверка критических значений, то и обработка просматривается лучше. (См. мой пример со скрытой опечаткой, которую нашли исключительно благодаря безисключительному :) методу).
3. Облегчает программирование - опять отмазка.
"Что бы мне такое делать, чтобы ничего не делать" (с)


"Классические" исключения крайне ограниченно применимы в случаях, когда "разработчик часто не знает, как именно должна обрабатываться исключительная ситуация (при написании универсальной процедуры чтения из файла невозможно заранее предусмотреть реакцию на ошибку, так как эта реакция зависит от использующей процедуру программы)", но во время исполнения есть возможность (а точнее -- необходимо) уточнить реакцию и повторить скорректированную операцию по месту. При исключениях происходит раскрутка стека и соответствующее разрушение состояния. Здесь уместна обработка исключений "с возвратом". К примеру, как техника "Conditions and Restarts" в Лисп:
http://lisper.ru/pcl/beyond-exception-h ... d-restarts

Как-то так механизм мог бы быть реализован через try-блоки:
http://axisofeval.blogspot.com/2011/04/ ... o-you.html

Эмуляция на С#:
https://habrahabr.ru/post/150198/

Реализация в Rust:
https://static.rust-lang.org/doc/0.8/tu ... conditions


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Август, 2017 21:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Руслан Богатырев писал(а):
Исключения предназначены отнюдь не только для обработки ошибок. Они образуют своего рода сигнальную шину, по которой передаются сигналы о важных событиях, связанных с выполнением программного кода. Как правило, нестандартные/нештатные события, которые требуют соответствующего арбитража.


Madzi писал(а):
Валерий Лаптев писал(а):
ИМХО на тему исключений.
...
Почему бывает, что на месте нельзя разобраться и обработать ошибку.
Допустим, в процедуру данные поступают из базы данных, а в базу данных они еще откуда-нибудь попадают (например, ручками вбиваются оператором или вообще с датчиков читаются).
Обрабатывающую процедуру кто-то вызывал - через десятые руки данные до нее дошли. И тут выясняется, что данные - плохие. Как раз в непрерывано работающих системах требуется, чтобы не было аварий, поэтому процедура должна сообщить отправляющему, что он прислал неформат. Пусть исправит и пришлет то, что нужно.
Передавать через 10-е руки коды ошибок - это кошмар, который пришлось переживать промышленным программерам в свое время. В этом смысле генерация исключения - это посылка сообщения "на предъявителя" - у кого есть соответствующий мандат - обработчик исключения.

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

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

Рискну предположить, что описывается событийная модель, которая может быть реализована с помощью исключений, но правильно её реализовать с помощью специальной очереди событий. "Каждой гайке - свой болт" (с)


Действительно, здесь в теме форума пытались в механизме исключений найти серебряную пулю. Пример выше про "conditions and Restarts" демонстрирует целесообразность специализированных инструментов. В качестве универсальных средств можно отметить технику "continuations", как в Scala:
http://lex-kravetski.livejournal.com/490165.html

Однако, подобные техники "на любителя".

В общем, исключения не отменяют потребности в какой-то модели управления "от данных". Будь то обмен сообщениями, какие-то события и пр.
Или здесь рядом была представлена Esterel-платформа, примерчик некоторых паттернов, в т.ч. и "исключений" при обработке данных:
http://www.ceu-lang.org/chico/ceu_rem13_pre.pdf

При наличии универсальных моделей dataflow, как Esterel/Lustre к примеру, фактически, снимается потребность в способах аля "conditions and restarts" и continuations. Механизм исключений аля "монады" дополняет эти модели для удобства реализации стратегии досрочного выхода при явной императивной последовательности.


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Илья Ермаков писал(а):
Со случаем алгоритмических ошибок, видимо, всё ясно... Либо программа работает, либо нет. Должны быть барьеры ошибок на неких уровнях рантайма, которые отвечают за обработку таких отказов и восстановление. Но это вообще внеязыковой вопрос.

Со случаем обработки особых веток событий в системах класса 24*356 ситуация интереснее... Даже если принять полезность try-except, то вот ведь какая штука. Эти средства расчитаны на текущие архитектуры ПО. Так скажем, "промежуточное", застрявшее на середине ООП - это касается всех вариаций, в том числе и КП (я бы даже сказал "шизофреническое" ООП, это ощущается из преподавания - эти механизмы противоестественны, они не идут "от задач"). Суть в том, что мы имеем множество (взаимо)действующих объектов, но при этом они приводятся в движение только одним (или небольшим количеством) потоков выполнения. И эти потоки "шуруют" насквозь через граф из огромного числа обьектов.

Однако естественно ждать перехода к нормальной ситуации, когда "каждый объект сможет поиграть собственным мячом" (С) "Хоттабыч". Собственно, это уже и наблюдается. Параллельное ООП на сообщениях, в котором вместо глубоких вызовов будет активация параллельного исполнителя. Собственно, у швейцарцев в Композите технически такая возможность уже обеспечена - когда вместо вызова процедуры в большинстве случаев идёт активация исполнителя (до миллионов...). До этого таким мог похвастаться Эрланг, но там таки не предлагалось такого упора на замену вспомогательных алгоритмов на параллельных исполнителей.

Так вот, если уж обсуждать проблему обработки особых ситуаций - то имеет смысл уже держать в уме такую перспективу. Как будем делать там, а? :) В Эрланге вот принцип простой - ошибка в процессе = "моментом в море" :) HALT, но, естественно, без раскрутки стека, на котором просто раскручивать нечего и не к кому...


К слову, миллион объектов -- скорее всего, это огромные проблемы, а не польза.
В Эрланге, кстати, аля деление на ноль -- перезапуск актора (при потребности). В аля С++ -- крах всего процесса (т.е. как бы всей виртуальной машины в сопоставление с Эрлангом).

Что касается исключительных ситуаций при реальной параллельности. Типовой приём -- практика асинхронных исключений. В качестве примера -- вводная статейка:
http://www4.in.tum.de/~wenzelm/papers/parallel-ml.pdf

где на С++ реализовано ядро Poly/ML. Ключевое: системный поток (thread) просто так "в лоб" рубить нельзя, если он использует какие-то ресурсы (mutex и т.п.), и необходимы "отложенные" исключения. В точке синхронизации -- "передача" исключения "клиенту" асинхронного процесса. И пр.


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

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1064
Откуда: СССР v2.0 rc 1
Сразу попрошу PSV100 больше не наливать!))

Ржавый не взлетит. Его философия стабильности и предсказуемости основана на более чем сомнительном фундаменте. Я не буду сильно умничать, просто приведу >оригинальную ссылку< куда более авторитетного товарища. К его описанию Ржавого ни дать не взять:
Цитата:
Чтение кода на Rust навевает шутки о том, как «друзья не позволяют друзьям пропускать день ног» и вызывает в голове комические образы мужчин с халкообразным торсом, балансирующим на тощих ногах. Rust ставит во главу угла безопасность и ювелирное обращение с памятью. В действительности, это довольно редко является настоящий проблемой, и такой подход превращает процесс мышления и написания кода в монотонный и скучный процесс.


В качестве подтверждения "тонких ног":
Цитата:
в Rust нет никакого простого способа отключить borrow checker. Даже внутри блоков unsafe он работает на полную мощность. Но borrow checker проверяет правила заимствования только для ссылок &T и &mut T, в то время как в unsafe-блоках у вас также появляется возможность использовать сырые указатели *const T и *mut T, которые работают практически аналогично указателям из C. Их использование никак не ограничено правилами заимствования.


Автор статьи откровенно не понимает о чём пишет (пытается нахваливать). Вот типичный комментарий (+8):
Цитата:
Эээммм?

Управление памятью — редкая проблема? Мне казалось, что это стало чуть ли не решающим фактором, позволившим джаве втоптать C++ в землю и забрать себе всю энтерпрайз разработку.


Далее по комментариям также достаточно расписан первородный грех Ржавого:
Цитата:
Да, есть базовые правила, вроде «никогда не может быть больше одной мутабельной ссылки». Но обычные ссылки – это далеко не все, что предоставляет вам Rust. Это только основа. Дальше у вас есть выбор из кучи инструметов, и возможность выбрать именно ту модель, которая наиболее приемлема для вас и вашей задачи.

Хотите – используйте unsafe. Хотите – используйте подсчет ссылок Rc/Arc. В ближайшем будущем у вас появится возможность еще и подключить сборку мусора, если захотите. И не просто подключить, а выбрать ту его реализацию, которая вам больше всего подойдет

И это сразу нет. В golang сборщик мусора был встроен сразу и никаких unsafe-ссылок там нет! Не потому ли, golang немножко мягко говоря впереди Rust? (* да, Кен Томпсон и Роб Пайк некрасиво поступили, взяв Оберон, прикрутив ему Си-синтаксис и прикрутив именованные каналы для мультипоточности *)

Правильно, что в Ржавом идёт попытка разделить исключения на два вида: собственно, исключение и панику. Но можете не сомневаться: Rust скатится к чуть более безопасному C++ ровно с такими же хроническими заболеваниями. Надо бы для порядка обратиться к старожилам, а в А2 или ОберонОС кто-нибудь, когда-нибудь ловил панику? Я очень сильно сомневаюсь...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Август, 2017 19:17 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
prospero78 писал(а):
Ржавый не взлетит...

Я совсем не о том, что мол давайте все срочно в Rust!!! Всего лишь приводил пример техники обработки исключений.
Вот ещё пример псевдо-исключений до кучи:
https://habrahabr.ru/company/tibbo/blog/258427/

Насчёт Rust. Вот презентация "guaranteeing memory safety" (не свежая, но принципиально сойдёт):
http://smallcultfollowing.com/babysteps ... 17-NEU.pdf

Среди подобного маркетингового материала, как правило, нет демонстрации как же "здорово" оперировать "регионами" в структурах данных. Там ещё муторнее, чем в рамках аргументов функции. Грубо говоря, в Rust-е пошли по пути смарт-поинтеров "с прикрытием" (в общем, не "бейсик" таки). Здесь возникает эффект "языка в языке", как и в С++. Т.е. в рамках конкретных проектов/команд разработчиков устанавливаются свои правила, способы, выбор конкретных средств и т.д.
Go потому и популярнее, что там гораздо проще.

Выше в теме была ссылка на пример из языка Ceu. Там неплохая база для реализации простого и удобного языка с контролем и без глобального GC ("регионы" там тоже не помешают, но в более простом применении).

prospero78 писал(а):
Правильно, что в Ржавом идёт попытка разделить исключения на два вида: собственно, исключение и панику. Но можете не сомневаться: Rust скатится к чуть более безопасному C++ ровно с такими же хроническими заболеваниями. Надо бы для порядка обратиться к старожилам, а в А2 или ОберонОС кто-нибудь, когда-нибудь ловил панику? Я очень сильно сомневаюсь...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Август, 2017 23:25 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1064
Откуда: СССР v2.0 rc 1
Соотношение сбоев "питание-железо-софт" примерно соответствует 1:10:100.
И любой сбой ниже уровня логики (т.е. паника) должен приводить к принудительному перезапуску. И можно как угодно область видимости обзывать: куст, узел, домен, регион, область, класс и что там ещё у кулхацкеров есть -- это не поможет. А разные возможные подходы в Раст -- это ещё усложнение для понимания кода (это главный параметр для оценки навыков программиста).
Алгоритмическая сложность + наворочанный синтаксис + грехи Си... Да подобные агрегаты просто не должны летать по всем законам. Не только Раст. Именно поэтому столько языков, и самый свежачок медленно но верно ползёт в сторону Оберон-технологии.
Неквалифицированные исключения (а таких я думаю на практике 95%) добавляют ещё немного хаоса. Зачем?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Август, 2017 19:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
prospero78, всё-таки, имеется какая-то неоднозначность.

В Rust-е, фактически, такой же подход в обработке ошибок как и в Оберонах (если я правильно их понимаю). Имеется "паника" -- аналог assert-а в Обероне (аварийный останов программы без каких-то прямых перехватов и восстановления). Если не ошибаюсь, где-то здесь в соседней теме про программирование "под доказательство" вы сами отмечали о важности assert-ов. В любом случае, "паники" неизбежны при реализации тех вещей, где невозможно иным способом информировать о нарушениях инварианта (реализация мат. операторов, операции индексации аля "a[...]" и т.п.). Однако, я не думаю, что в Обероне "паникуют" (т.е. окончательно прерывают программу), напр., при неудачном открытии файла. Это в языках аля Java/Scala и пр. вполне можно ожидать вылет "прикладного" exception-а в API для файлов. В этой сфере срабатывает эффект общественности -- везде, во всех API сплошь и рядом исключения, и в итоге все вынужденны кидать исключения (что по-своему и полезно: пусть безобразно, но зато однообразно). К тому же модно подталкивать к коду в стиле:
"a = OpenFile(...).MkString(...).Split(...)" , где без исключений ни как.

В Rust-е также нет "классических" исключений. Когда необходимо, результат операции возвращается явно, нет никаких случайных "выбросов" прикладных исключений и прерываний программы. Такие вещи, как оператор "?" и блок try-catch -- всего лишь синтаксический сахар для досрочного выхода из функции и установки её соответствующего результата. Ограниченно, поскольку предполагается универсальный тип "Result<T, E> = Ok(T) | Err(E)". Достаточно во многих случаях, но семантика результатов может быть и иной, к примеру, как возврат кортежа из трёх элементов: прикладные данные, информация об ошибке, признак окончания данных. Причём все элементы могут произвольно быть при каждом исполнении операции (т.е. предметные данные могут быть получены и при наличии ошибки, и не всегда ошибка не допускает последующую итерацию).
А ранее здесь в теме была отмечена проблематика исключений при повторении операций (а также и при потребности "откатов" изменений, хотя в целом тут и при "кодах ошибки", т.е. и без исключений необходимо выкручиваться, и не только "классическим" способом -- через временные объекты и окончательный "swap" при успешной транзакции). И исходя из всего выше изложенного можно обратиться к самому началу темы:
Alexey_Donskoy писал(а):
Предлагаю здесь без лишних слов привести пару учебных примеров, на которых показать пользу или вред исключений.

Исходные тезисы противоречивы:

1) исключения - неструктурны и поэтому ухудшают качество программы (в том числе когнитивные качества и потенциальную вероятность ошибок);

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

В процессе изучения механизма исключений также придётся решить подзадачу:
а) анализ практической потребности прерывать алгоритм до завершения;
б) как правильно и оптимально это сделать? :)

и утвердить, что, как минимум, исключения не обеспечивают "свёртку невообразимо сложного графа реакции на все потенциально возможные ошибочные ситуации" (а в целом -- не только ошибочные). Но одновременно и подход без "прикладных" исключений сам по себе ни как не реализует "невообразимо сложного графа реакции на все возможные ситуации". К тому же понимание "структурности" программы здесь весомо рассматривается. И сама эта тема возникла из:
http://forum.oberoncore.ru/viewtopic.php?f=7&t=1443

где поломано немало копий с разных сторон. И исторически не последнюю роль в понимании "структурности" на здешних просторах сыграл Дракон. И сейчас подобные баталии иногда возникают, как:
http://forum.drakon.su/viewtopic.php?f=62&t=6036

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

В рамках "Оберон-подхода" (назову это так) напрасно игнорируется подход управления "от данных", как здесь:
viewtopic.php?f=152&t=6049

где и на "структурность" совсем по-другому смотрят, и проблемы "с реакцией на всевозможные ситуации" решают (и именно решают). Там "классические" исключения лишь только мешают. Однако, притирка "data centric" и "control centric", всё-таки, требуется исходя из возможностей/пожеланий конкретного языка/платформы.

Иными словами, самого по себе минимализма в стиле Оберон-а не достаточно, иначе подобные темы здесь и не возникали бы.


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

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


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

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


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

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