OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 25 Март, 2019 20:54

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




Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу 1, 2, 3, 4, 5 ... 9  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 04 Январь, 2008 19:47 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Тут же к вопросу об обработке исключений - мне кажется, что конструкции try-except (в полезности которых многие давно сомневались) совершенно бесполезны в параллельных приложениях. Т.к. искать обработчик исключительной ситуации раскруткой стека текущего потока бессмысленно, этот поток не может и не должен ничего знать об обработке исключений (а если всё-таки должен, то достаточно обычных кодов ошибок).
Обработчики исключений должны быть обычными callback-объектами, с соотв. конкретным возможным проблемам интерфейсами. Приложение описывает эти обработчики и регистрирует их в соотв. службе. Т.е. никаких спец. языковых механизмов, только обычные ОО-паттерны.

Я тут подумал -- а зачем ещё и паттерны ООП привлекать-то? :о))

Вот возьмём (ну конечно же) тот же Хаскелл. В нём нет специальной языковой конструкции тип try-except, есть просто несколько стандартных функций: catch, try, bracket, finally для обработки исключений и ioError -- для их генерации...

Простейший пример:
Код:
main = do
    print $ 1 `div` 0
Как и следовало ожидать, при выполнении образуется исключение: divide by zero. Как его перехватить? Ну, например, вот так:
Код:
import Control.Exception as CE

main = do
    print $ 1 `div` 0
  `CE.catch` \err -> print $ "Oops! Something wrong: " ++ show err
А если надо просто попытаться выполнить какой-то код, игнорируя возможные ошибки, то можно сделать так:
Код:
import Control.Exception

main = do
    try $ print $ 1 `div` 0

Функции try и finally являются аналогом оператора try-finally в Дельфях. Позволяют делать так:
Код:
import Control.Exception

main =
  try $ do
    open_resources              -- открываем какие-нибудь файлы или прочие ресурсы
    do_something                -- делаем что-то, что может привести к исключению
 `finally`
    close_resources             -- закрываем открытые ресурсы
Или более продвинуто -- с обработкой возникших неприятностей:
Код:
import Prelude hiding (catch)
import Control.Exception

main =
  do
    open_resources              -- открываем какие-нибудь файлы или прочие ресурсы
    do_something                -- делаем что-то, что может привести к исключению
 `finally`
    close_resources             -- закрываем открытые ресурсы

 `catch` \err -> case err of    -- Обрабатываем возникшие исключения
    ArithException DivideByZero -> print "Oops! Division by Zero"
    Deadlock                    -> print "Oops! All threads are blocked"
    others                      -> print $ "Oops! " ++ show others

Функция bracket чем-то похожа на оператор using из C#. Можно делать, например, так:
Код:
main = do
    bracket
        (openFile "filename" ReadMode)  -- открываем файл
        (hClose)                        -- закрываем его, что бы ни случилось
        (\handle -> do { ... })         -- если открылся нормально, работаем с ним
Любимый лисперами макрос with-file будет выглядеть так:
Код:
withFile name mode = bracket (openFile name mode) hClose
и все дела! Вот она, сила функционального программирования! :о) Новая продвинутая (для каких-нить там джавистов или сишарперов) языковая конструкция задаром, просто в виде функции!

С одной стороны, такой набор гибких функций, а не жёстких операторов, может выглядеть моментами как привносящий некоторый синтаксический оверхед (типа `catch` \err -> case err of), что не очень приятно, но вполне терпимо.

С другой стороны, это позволяет при необходимости вносить в логику обработки исключений свои собственные поправки/изменения/дополнения, не затрагивая компилятор или стандартные библиотеки...
Например, Булат Зиганьшин в своём архиваторе FreeArk легко сделал такие поправки, что бы перехватывать нажатие на Ctrl-C и корректно закрывать все файлы и прочие дела при этом...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 20:11 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Geniepro писал(а):
Я тут подумал -- а зачем ещё и паттерны ООП привлекать-то? :о))
...
Вот она, сила функционального программирования! :о) Новая продвинутая (для каких-нить там джавистов или сишарперов) языковая конструкция задаром, просто в виде функции!


В том-то и дело, что её продвинутость сильно сомнительна. И "задаром" ну никак не надо - именно потому, что все тут же её начинают направо и налево использовать.

А в единственном случае, когда она нужна - высокоуровневая служба над ненадёжной средой, обработка тех ситуаций, когда служба не может выполнить контракт - её ЛУЧШЕ, чем языковая конструкция, решит обычная точка расширения через ОО-разъём.

Видите, сколько соблазнов от этих ваших наворотов - сразу конструкцию, и сразу задарма :-) Вместо того, чтобы сначала хорошенько подумать. Любое техническое решение чего-то стоит. И если стоимость спрятана от поверхностного взгляда, это не значит, что её нет. Стоимость ФП совершенно не ясна (хотя чрезмерная сложность и толщина "подложки" таки видна) - а её прояснению мешают сами же ФП-шники, утверждающие, что "у нас всё нахаляву".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Январь, 2008 22:00 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
В том-то и дело, что её продвинутость сильно сомнительна. И "задаром" ну никак не надо - именно потому, что все тут же её начинают направо и налево использовать.


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


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

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Цитата:
В том-то и дело, что её продвинутость сильно сомнительна. И "задаром" ну никак не надо - именно потому, что все тут же её начинают направо и налево использовать.
Вот есть два подхода к программированию -- наращивание исходного языка до уровня, в котором он является просто языком описания и обработки предметной области, позволяющем программисту думать не о байтах и битах, не о семафорах и процессах, не о WHILE и foreach/break, а о самой задаче.

И есть ещё второй, давно уже устаревший низкоуровневый подход...


Обычно компактные языки с расширяемым синтаксисом (как Лисп/Схема, Немерле, Смоллток) или другими удобными возможностями для создание eDSL (как Хаскелл, ML-семейство) используются индивидуалами.

Промышленные языки же наоборот -- имеют жёстко стандартизированный богатый набор встроенных конструкций на все случаи жизни, изменять который можно только раз в 10 лет... :о)

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

Кстати, Илья, вот Вы часто упоминаете метапрограммирование на Компонентном Паскале, а не могли бы Вы продемонстрировать какой-нибудь типичный пример его использования, что бы все сразу ахнули и сказали: "Да, определённо в этом что-то есть..." ;о)

Цитата:
Вместо того, чтобы сначала хорошенько подумать. Любое техническое решение чего-то стоит.
...
Стоимость ФП совершенно не ясна (хотя чрезмерная сложность и толщина "подложки" таки видна) - а её прояснению мешают сами же ФП-шники, утверждающие, что "у нас всё нахаляву".
Да тут такая вот проблема -- начинающие функциональщики ещё не знают, какова она, эта Ваша "стоимость ФП", а продвинутые функциональщики уже просто забыли про эту самую стоимость... :о))

ФП до сих пор и, наверное, ещё долгие годы будет программированием для одиночек, которые именно в одиночку выполняют объёмы работ, для которых в других случаях требуются десятки "мартышек-кодеров"...
В этом и есть основная проблема ФП... :о)


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

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Geniepro писал(а):
Оберон в этом плане выбивается -- он вроде и компактный язык чисто для индивидуалов, но при этом не имеет других возможностей для расширения, кроме громоздких в создании и использовании процедур и иерархий типов. Странно как-то...

В Обероне основной инструмент расширения -- модульность.

Geniepro писал(а):
Кстати, Илья, вот Вы часто упоминаете метапрограммирование на Компонентном Паскале, а не могли бы Вы продемонстрировать какой-нибудь типичный пример его использования, что бы все сразу ахнули и сказали: "Да, определённо в этом что-то есть..." ;о)

Как иллюстрация возможностей метапрограммирования вполне подошло бы введение обработки исключений (как раз на заданную тему :) ).
Zero-Overhead Exception Handling Using Metaprogramming (1996)
http://oberon2005.ru/paper/p_ex.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 00:18 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
AVC писал(а):
Zero-Overhead Exception Handling Using Metaprogramming (1996)
http://oberon2005.ru/paper/p_ex.pdf


1. Где реализация для BB?
2. Как реализовать FINALLY?
2. Как потом переносить исходники за пределы BB?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 01:46 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
AVC писал(а):
В Обероне основной инструмент расширения -- модульность.
Это инструмент расширения программы как совокупности модулей (инженерно-техническое сооружение), а не самого языка как языка описания и манипулирования объектами предметной области.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 03:53 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Geniepro писал(а):
AVC писал(а):
В Обероне основной инструмент расширения -- модульность.
Это инструмент расширения программы как совокупности модулей (инженерно-техническое сооружение), а не самого языка как языка описания и манипулирования объектами предметной области.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 04:12 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Vlad писал(а):
AVC писал(а):
Zero-Overhead Exception Handling Using Metaprogramming (1996)
http://oberon2005.ru/paper/p_ex.pdf


1. Где реализация для BB?

Не знаю, я не брал. :)
Принципиальной разницы между ББ и ETH-Обероном нет, так что подобное решение вполне возможно и в ББ.

Vlad писал(а):
2. Как реализовать FINALLY?

Хотя бы вызывая одну и ту же вложенную процедуру (можно даже назвать ее Finally :) ) как при нормальном завершении подпрограммы, так и из обработчика исключения.
Vlad писал(а):
3. Как потом переносить исходники за пределы BB?

По видимому, вместе с соответствующим модулем обработки исключений.
Или просто переносить ББ. :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 05:36 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
AVC писал(а):
Цитата:
1. Где реализация для BB?

Не знаю, я не брал. :)
Принципиальной разницы между ББ и ETH-Обероном нет, так что подобное решение вполне возможно и в ББ.


А. Ну как всегда. А потом кто-то удивляется нулевой популярности BB.

AVC писал(а):
Vlad писал(а):
2. Как реализовать FINALLY?

Хотя бы вызывая одну и ту же вложенную процедуру (можно даже назвать ее Finally :) ) как при нормальном завершении подпрограммы, так и из обработчика исключения.


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

AVC писал(а):
Vlad писал(а):
3. Как потом переносить исходники за пределы BB?

По видимому, вместе с соответствующим модулем обработки исключений.
Или просто переносить ББ. :)


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 13:41 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Vlad писал(а):
А. Ну как всегда. А потом кто-то удивляется нулевой популярности BB.

Это замечание следует адресовать Oberon Microsystems (и, возможно, орловцам).
Вопрос Geniepro был о примерах применения метапрограммирования в Обероне.
Кроме посмертного отладчика и (возможной) обработки исключений, сюда можно отнести практически весь пользовательский интерфейс: коммандеры и меню основаны на вызовах процедур по имени, диалоги также используют метаинформацию.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 15:44 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Vlad писал(а):
И если в языке делать это обработку непросто (проводится политика "нам это не нужно, потому что у нас есть коды возвратов, а если коды для вас не модно, то извращайтесь с ООП разъемами"), то на практике это приводит к тому, что ошибки или не обрабатываются (игнорируются) или обрабатываются "на отвяжись" (в лучшем случае возвращается невнятный код ошибки).

И Вы тоже не поняли мысли... Саму тему Geniepro начал отсюда: viewtopic.php?p=11906#p11906 - там упоминалось мнение Бертрана Мейера по поводу обработки исключений.
Ошибки, про которые Вы говорите (при взаимодействии с внешней средой) - это пока ещё НЕ ИСКЛЮЧЕНИЯ. Не исключения до тех пор, пока их можно делегировать на верхний уровень. Т.е. пока это ожидаемо. И здесь лучше коды ошибок.

Речь идёт о ситуации, когда делегировать выше мы не можем - потому что наша служба имеет высокоуровневый интерфейс, который имеет контракт (пред-постусловия) более сильный, чем можно обеспечить на базе слоя, лежащего ниже. Например, мы дали выше абстракцию абсолютно надёжной связи, а ниже-то лежит сеть, из которой узел может в любой момент пропасть... И вот это уже действительно исключение, потому что связано с нарушением контракта. И нужно эту разницу в контрактах компенсировать. Только делегация вверх по стеку в таких ситуациях часто бессмысленна, особенно в параллельных приложениях. Так что try-catch оказывается бесполезен. А выручают "разъёмы". Так на кой мне в языке тот механизм, который в единственном реально нужном и важном случае не позволяет организовать обработку НАСТОЯЩИХ исключений? (а не багов, кои должны обрабатываться ASSERT + библиотечной try-обёрткой где-то на уровне главного цикла сообщений приложения, и не предусмотренных ошибок, которые делегируются всегда точно на уровень вверх и для которых ничего лучше кодов ошибок не придумано...)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 15:58 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Geniepro писал(а):
Кстати, Илья, вот Вы часто упоминаете метапрограммирование на Компонентном Паскале, а не могли бы Вы продемонстрировать какой-нибудь типичный пример его использования, что бы все сразу ахнули и сказали: "Да, определённо в этом что-то есть..." ;о)

Да возьмите стандартную подсистему Sql из BlackBox и посмотрите на её возможности. Отображение типов языка на таблицы происходит так же прозрачно и удобно, как, ну например, в PHP. Или возьмите BlackBox Lab - самый типичный школьный интерпретатор получился. Только без интерпретатора :-)

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

Мелкий, но надоевший пример - "есть ли жизнь без break". Я б про него не вспомнил в очередной раз, но просто недавно прочёл хорошее сравнение, он высказано было совсем по другому поводу психологом Леонтьевым.
Представьте себе, что людям, никогда не видевшим велосипедов, попадаются два экземпляра: трёхколесный и двухколёсный. Как вы думаете, какой им покажется более удобным и естественным? Конечно, трёх. И попробуйте объяснить им обратное (если не можете показать). Они покрутят пальцем у виска и скажут: "Вы что, как можно ездить без третьего колеса? Это ж неудобно!" А если начнёте доказывать, что удобно, то скажут: "Можно, конечно, но ведь это всё время ногой об землю толкаться придётся..." ("ну, ведь это лишние булевы переменные заводить и проверки" :-) ).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 16:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Цитата:
Да тут такая вот проблема -- начинающие функциональщики ещё не знают, какова она, эта Ваша "стоимость ФП", а продвинутые функциональщики уже просто забыли про эту самую стоимость... :о))

История знакомая. Когда-то "начинающие С++-сники тоже не знали... А продвинутые за красивой комбинаторной игрой уже забыли..." А теперь расхлёбывать... То же самое стало с ООП... и т.д.

Цитата:
ФП до сих пор и, наверное, ещё долгие годы будет программированием для одиночек, которые именно в одиночку выполняют объёмы работ, для которых в других случаях требуются десятки "мартышек-кодеров"...

При условия попадания на естественный для ФП спектр задач. То же самое касается и Оберонов, например, для системного программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 16:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Давайте, например, поговорим про цену первого попавшегося механизма из ФП - автовывода типов.
ФП-шники тут же обычно поднимают гвалт - "нету никакой цены, всё то же самое..."
Потому что за своими кисельными реками берега уже разучились видеть :-)

Так вот, если брать компилируемые реализации ФЯ, то автовывод типов - это всё равно, что превратить каждую обычную функцию в template. Т.к. потенциально множество типов, с которыми функция может работать, бесконечно и не зафиксировано жёстко в определении самой функции. Таким образом, ставьте сразу крест не только на динамическом расширении системы, но и даже на раздельной компиляции. Если Вас и Jack Of Shadows такая цена не пугает (ну не нужны вам эти возможности) - я за вас рад! :-) Но конкретная цена механизма названа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 16:11 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Geniepro писал(а):
AVC писал(а):
В Обероне основной инструмент расширения -- модульность.
Это инструмент расширения программы как совокупности модулей (инженерно-техническое сооружение), а не самого языка как языка описания и манипулирования объектами предметной области.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 16:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
Vlad писал(а):
Особенно извращенно это будет выглядеть для случаев, когда надо всего лишь сделать какой-нибудь Close(resource) (а таких случаев - большинство).

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


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

Зарегистрирован: Суббота, 12 Май, 2007 08:41
Сообщения: 102
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
т.к. закрытие, например, файла, открытого на чтение, можно спокойно переложить на сборщик мусора, подбирающий объект типа File и вызывающий его финализатор).

Подобрать то он подберёт, но когда он это сделает - большой вопрос. А до этого момента файл будет недоступен для других процессов/потоков. Так сказать, временная утечка ресурсов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 17:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9099
Откуда: Россия, Орёл
ну, я же сказал - "открытого на чтение", подразумевая, что в SHARED MODE...
Например, документы в BlackBox открываются именно в таком режиме. Может быть открыто несколько Files.File на один документ разными модулями (на самом деле там возвращается один и тот же, он ищется среди уже существующих объектов данного типа), а закрывается только сборщиком мусора...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Январь, 2008 19:34 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Ошибки, про которые Вы говорите (при взаимодействии с внешней средой) - это пока ещё НЕ ИСКЛЮЧЕНИЯ.


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

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


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

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


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

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


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

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