Ответ на »сообщение 5124« (pepper)
___________________________

Ответ на »сообщение 5120« (Илья Ермаков)
___________________________
Зачем приплетать сюда постусловия и нагружать их дополнительной семантикой - мне непонятно. Стремление не вводить нормальный механизм исключений и идти своим путем?
Что значит "приплетать"? А Вы что, проектируете интерфейсы без формальной спецификации постусловий на каждый вызов?
Стремление "ввести", как я выше описал, было, и как быстро оказалось, исключения в моей задаче были бы совершенно бесполезны.

Ответ на »сообщение 5122« (Илья Ермаков)
___________________________


Да, схема та, и вот я тоже не пойму, чем в большинстве случаев плох код ошибки, чтобы ещё вводить обработку исключений?


Было большое обсуждение. Кстати, началось с оберона ;)
http://www.rsdn.ru/Forum/message/1501117.flat.1.aspx

Ответ на »сообщение 5120« (Илья Ермаков)
___________________________



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


Про это уже сто раз говорили.
1) Никто не заставляет вызывающий код контролировать коды ошибок (только не надо опять начинать песню про культуру программирования и про идельных пограммистов). Исключения дают гарантию, что кривой код (не обработавший ошибку) не будет косячить дальше с фиг знает какими данными.
2) Протаскивание ошибок через параметры замусоривает код и добавляет уровни вложенности в if/else. Простая и наглядная запись f1(f2(f3()))) превращается в мусор.
3) Если какой-то компонент стал сигнализировать об ошибке, то не надо менять кучу интерфейсов, которые раньше не сигнализировали об ошибке.


В этом случае я вообще не вижу смысла в исключениях. Это своего рода "валерьянка" для С++-сникорв в стиле "что бы там на нижних слоях не накосячили, но вот тут я защищусь, и всё будет в порядке".


Я явно оговорил, что сейчас речь идет исключительно об обработке ошибок физического мира. Не надо сюда припутывать косяки C++. Модель исключений замечательно себя зарекомендовала не только в этом языке.


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

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

Ответ на »сообщение 5117« (Стэн)
___________________________

Ответ на »сообщение 5108« (Руслан Богатырев)
___________________________
>>> Яркий пример компьютера, который работает у массового потребителя круглосуточно, -- мобильный телефон. Именно он в будущем станет той самой "волшебной палочкой", которая заменит очень многое: работу с банковским счетом, покупками, управление бытовыми устройствами и электронными система помещения и многое-мнгое другое.

Есть какие-либо перспективы у Оберонов в этом сегменте, либо там будут Java/.NET?

Ну, по крайней мере на 100 млн. устройств Оберон используется... Правда, под Java-обёрткой. :-)
Я говорю об известнейшей компании Esmertec, мировом лидере по встроенной Java.
Историю этой компании процитирую из блога Р. Богатырёва:
http://rbogatyrev.livejournal.com/2007/08/24/


В 1993 г. три друга, три товарища, учившиеся аспирантуре в швейцарском ETH, основали компанию Oberon microsystems. Их звали Cuno Pfister, Clemens Szyperski (ныне в Microsoft Research), Beat Heeb. В 1994 г. они сделали первый вариант BlackBox. Хотелось создать своими руками хорошую среду, чтоб и Оберон заиграл и народ полюбовался, как здорово работают идеи Вирта и Гуткнехта.

И все бы ничего, но тут как гром среди ясного неба грянула Java. Что делать? Срочно была предпринята коллективная ревизия Оберона — "наш ответ Чемберлену". Собрали военный совет, тут добавили, там подправили — вот оно, что-то вышло. Новоиспечённому языку дали (из рыночных, как они говорили, соображений) имя Компонентный Паскаль (Component Pascal). Было это в 1997 г. Вирта позвали в крёстные отцы. Что делать — согласился, надо же поддержать молодёжь.

[Пишу по памяти — весной 1998 г. готовил публикацию по Компонентному Паскалю в ComputerWeek-Moscow и связался с Куно Пфистером. Тот живо откликнулся и прислал материал, который и пошёл в печать. В то время у них уже была своя ОС реального времени для встроенных систем с именем Portos.]

В 1999 г. от Oberon microsystems отпочковалась компания Esmertec. Создавали её уже четыре "танкиста" — Daniel Diez, Beat Heeb, Hansruedi Heeb и Peter Eichenberger. Во многом развитию нового направления способствовал потенциал той самой Portos. Эта ОС поддерживала два языка — Компонентный Паскаль (спец. версию для задач реального времени) и Java. Ядро реального времени делалось, разумеется, не на Java. Ну а инструментарий для кросс-разработки (на базе BlackBox) нарекли именем Denia — курортное местечко в Испании, на Коста-Бланка. Portos не нужна была ни виртуальная машина, ни интерпретатор кода, ни JIT-компилятор. Использовались идеи М.Франца.

Попытки продвинуть Змей-Горыныча о двух головах (CP/Java) заметным успехом не увенчались. Очень уж мешалось название "Компонентный" да ещё "Паскаль" в сфере микромира. Java — это класс, Java — это сила! Правильно. Сделали ставку на раскрученную вещь, зная, что уж она у них работать будет, как часы. Portos переименовали и стёрли с карты мира (чтоб никто и не вспоминал). Теперь "героя Дюма" звали Jbed — "ложе для Java". Брат Пфистера — Бернд подсуетился насчёт инвестиций, основал свой фонд, начал накачивать денег. К делу подключили связи по Европе — Франция, Германия, Швейцария. Идея народ вдохновила — ещё бы, Sun ещё там только на бумаге чертила красивые диаграммы, расставляла столбики с надписью "Java Micro Edition — руками не трогать", а они взяли и рванули. На святое замахнулись, на самое ядрёное ядро. Кто помнит, Java ведь с этой идеи начиналась, захвата микромира — "мы им там всем покажем кузькину мать!".

К началу 2007 г. количество устройств, в которых используется Jbed, достигло 100 млн. штук. Стали мировым лидером в области J2ME. Верховодил в компании француз Alain Blancquart. Кстати, ушёл в никому не известную Esmertec из Borland Europe, где занимал высший пост. Стала сколачиваться нехилая команда, пошли люди из IBM Europe, а теперь — стоит глянуть на топ-менеджмент и совет директоров: что ни персона, то ого-го!

    * Michel Bon — 8 лет возглавлял France Telecom
    * Ulrich Schumacher — бывший президент Siemens Semiconductor Group
    * Jean-Pascal Aubert – бывший вице-президент Bull
    * Michel Kuntz – бывший вице-президент Alcatel
    * Sylvie Vollet – бывший топ-менеджер Apple Computer Europe
    * Chase Bailey — бывший главный технолог в Cisco
    * Jean-Luc Gianduzzo – 12 лет проработал в топ-менеджменте Hewlett-Packard, затем занимался развитием новых технологий в Cisco Systems Europe.


А Бернд Пфистер выбивал и выбивал денюжку. Европейские инвесторы просто помешались на этой компании. Золото, золото! Про Обероны забудьте. Нет у них такого слова. На чём работает Jbed — ни за что не скажут — военная тайна. А тем, кому нужна особая эффективность в микромире, – есть скрытый шлюз Компонентного Паскаля. Как говорится, обращайтесь, господа — сделаем на заказ.

Ответ на »сообщение 5121« (Стэн)
___________________________

Ответ на »сообщение 5120« (Илья Ермаков)
___________________________
И если та, которую я описал, то чем плох вариант, когда есть простая функция, которая либо соединяется, либо нет и возвращает код ошибки (причины невозможности соединения), а вызывающий код (он в роли управляющего) решает, что делать - повторить попытку, повторить попытку с новыми параметрами...
Да, схема та, и вот я тоже не пойму, чем в большинстве случаев плох код ошибки, чтобы ещё вводить обработку исключений?
Я столкнулся как раз с тем небольшим множеством случаев, когда код ошибки плох...
Когда в системе, просто в силу её архитектуры, возникает слой абстракции, который должен выглядеть абсолютно надёжным, без всяких кодов ошибок, хотя ниже может лежать ненадёжная среда. К примеру, вызов метода удалённого объекта, через прокси-объект. Делая вызов, я не знаю, что за объект и где он находится, вообще не знаю, что идёт работа с сетью... Какие могут быть коды ошибок? А ошибки-то возникать будут. И обработать их внутри системы удалённого вызова самостоятельно, без знания того контекста, в котором происходит использование, в ряде случаев невозможно. Вот и требуется делегирование решения проблемы на верхний уровень компонентной системы.
Казалось бы, как раз то, для чего создавлись try-catch. Делегирование проблемы "наверх", без замусоривания лишними параметрами для кодов ошибки, как бы "боковым каналом управления". А вот фигушки - я очень быстро понял, что try-catch здесь не помог бы никак. Именно в силу вышеописанной проблемы - иерархия активаций на стеке не имеет в компонентной и тем паче параллельной системе никакого отношения к иерархии компонент и уровней ответственности.
Таким образом, после промелькнувшего ощущения, что "вот бы обработку исключений..." я опять вернулся к мнению о практически полной бесполезности этого механизма в языке (я не имею в виду низкоуровневых средств, которые в ядре того же ББ есть, которые позволяют выстроить в центре системе обработку программных сбоев) и был вынужден изобретать схемы в рамках "нормальных" языковых конструкций...

Ответ на »сообщение 5120« (Илья Ермаков)
___________________________
>>> А я вообще начал разговор об исключениях, если перечитаете начало, именно применительно к тем ситуациям, когда верхний уровень должен создать иллюзию большей надёжности, чем нижний уровень, усилить постусловия. Для этой задачи, как оказывается, исключения бесполезны. А единственный способ - выстраивание побочных "обратных связей", через которые наверх (но не вызывающему коду, а конкретному, заявившему себя в начале работы) делегируется решение тех ситуаций, которые попадают в "щель" между постусловиями...

Илья, выражение "верхний уровень должен создать иллюзию большей надёжности" выглядит несколько неоднозначно... ;-)

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

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

Ответ на »сообщение 5118« (pepper)
___________________________

Ответ на »сообщение 5109« (Илья Ермаков)
___________________________


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

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

Ответ на »сообщение 5110« (Илья Ермаков)
___________________________


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

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

Ответ на »сообщение 5109« (Илья Ермаков)
___________________________


В случае ошибки компонента DVD должна обратиться к верхнему уровню системы с запросом "что делать", на верхнем уровне может либо быть сделан запрос к пользователю (типа Ab,Ret,Ign...), либо попытка восстановить соединение, либо ожидание, после чего с верхнего уровня возвращается результат - что делать дальше... Например, отдаётся новый хэндл файла, либо говорится его пропустить... При этом клиент сервиса записи ничего даже не замечает, обратное обращение идёт по боковому callback...

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

Ответ на »сообщение 5108« (Руслан Богатырев)
___________________________
>>> Яркий пример компьютера, который работает у массового потребителя круглосуточно, -- мобильный телефон. Именно он в будущем станет той самой "волшебной палочкой", которая заменит очень многое: работу с банковским счетом, покупками, управление бытовыми устройствами и электронными система помещения и многое-мнгое другое.

Есть какие-либо перспективы у Оберонов в этом сегменте, либо там будут Java/.NET?