Здравствуйте, Ночной Смотрящий, Вы писали:
ХГД>>Ее в любом случае придется делать
НС>В веб-фреймворках давно уже все готовое, только подключить.
Чего готовое? У меня, к примеру, к разным плюсовым объектам разные юзеры имеют разные уровни доступа. Это кто за меня напишет?
НС> Вплоть до openid аутентификации на всяких гуглях и фейсбуках. НС>И это только маленький кусочек мозаики. Ты не представляешь какую кучу всякой фигни тебе придется решать — бандлинг и минификация скриптов и стилей, версионирование статики, поддержка websockets и нотификаций и еще стадо всяких веб-специфичных моментов. И ради чего?
На самом деле все давно сделано. Но щас новую верию затеваем, под новые требования, вот думаю может пересмотреть чего — старой то 10 лет скоро.
НС>Просто чтобы не писать простенький JSON сериализатор?
Чего? Для выдачи HTTP из C++ как раз и приходится писать только JSON сериализатор
ХГД>> Да и вообще она например 8 лет назад сделана для нейтив клиентов.
НС>А для серверов?
Ась? Каких серверов?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ну тогда и ответ такой же — без разницы. Технологий как интеропа, так и межпроцессного взаимодействия в дтнете навалом, выбирай любую по вкусу. ХГД>>Осталось показать, что их применение имеет какие-то преимущества, по сравнению с отдачей HTTP прямо из плюсового кода
НС>Преимущество имеет ASP.NET MVC, который позволяет создавать веб-приложения в несколько раз быстрее, чем на С++
Вот слабо верится. У меня сейчас плюсы выдают динамику сразу в JSON, и я в упор не вижу, где там можно аж в несколько раз сэкономить. На клиенте GWT втыкает данные из этого JSON куда надо и все более-менее работает. Хотя есть отдельные косяки и сейчас как раз подходящий момент чтобы спроектировать все по-новой.
НС>>>Обычная dll либо mixed mode сборка на С++/CLI вполне подойдут. ХГД>>Т.е., мне придется имеющийся код переделывать на С++/CLI?
НС>Я словосочетание mixed mode для кого написал? Ничего переделывать не надо.
Если я в C++ коде кину std::runtime_error, как мне его в ASP ловить? Надо, например, в таких случая 500 выдавать с текстом из исключения. Ну и на некоторые типы исключений специальным образом реагировать — где-то 403 выдавать, где-то редиректы делать и т.п.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Для того чтобы знать что конкретно требуется тщательно проверять и не разрешать лишнего — нужен fine-grained контроль за отдельными функциями НС>CLR это позволяет. На сборки навешивается только общая политика, так что не программистом задается, а администратором. А разметка кода вполне опускается до уровня конкретных методов.
Какие keyword'ы поискать по теме?
НС>>>Я ж говорю, изобретаешь CLR. EP>>Ок, как определить используется ли в вызываемом методе операции, которые могут привести к переполнению целых? НС>Есть соотвествующие метки контекста.
Метки кто расставляет?
EP>> Или, например, возможен ли вылет исключения? НС>Тут все совсем просто — вылет исключения возможен всегда. Только какое это имеет отношение к безопасности? CLR не С++, неперехваченное исключение память не портит.
С исключениями как раз в C#/Java проблем больше, using'и/try-with-resources это полумера, с транзитивностью распространения is-a-resource никак не помогает. Тема уже не раз обсуждалась.
Но суть в другом — если код не готов к исключению, то оно может поломать инварианты, грубо говоря прервать транзакцию на пол пути. Обвешивать избыточными try/using'ами — тоже не всегда оправданно. Более того, откатить "транзакцию" до приемлемого состояния даже не всегда возможно. Поэтому иногда приходится требовать чтобы некоторые операции не кидали исключений.
Опять таки, в Haskell'е есть монада Exceptional: не заметить что вызываемый код может "выкинуть" исключение — никак нельзя. И это форсится языком — у функции которая "кидает" исключение просто другая сигнатура, и использовать таким же образом как обычную уже не получится.
А к безопасности это имеет самое прямое отношение — большинство проблем с безопасностью происходят от нарушения предусловий/инвариантов, пусть и не всегда явных.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Чего готовое? У меня, к примеру, к разным плюсовым объектам разные юзеры имеют разные уровни доступа.
А аутентификация как? basic и хватит?
ХГД>>> Да и вообще она например 8 лет назад сделана для нейтив клиентов. НС>>А для серверов? ХГД>Ась? Каких серверов?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, artelk, Вы писали:
_>Я в предыдущем сообщение несколько сумбурно всё написал, смешав совсем разные вещи. Сейчас попробую систематизировать.
_>И так, у нас речь о выполнение неких задач параллельно (действительно параллельно или скажем "поочерёдно").
Речь о большом множестве (во много (например, в тысячи раз) больше, чем количество ядер) одновременных задач, каждая из которых, помимо небольшой нагрузки на CPU, выполняет асинхронные IO операции. Задачи добавляются в течение работы приложения динамически, если это имеет значение. Вобщем у нас некий типичный сервис, от которого требуется высокая масштабируемость.
Внутри одной конкретной задачи никакого распараллеливания не нужно — у нас и так другие ядра будут почти всегда заняты.
_>Я бы разделил всю эту большую область на две отдельные части:
_>1. Когда не требуется небольшое число одновременных задач.
Когда не требуется большое число одновременных задач?
_>В данном случае на мой взгляд самым оптимальным является использование системных потоков (и соответственно блокирующего IO). Возможно кто-то не согласится (готов подискутировать и даже потестировать), но я не вижу ни единого аргумента в пользу других решений.
Если одновременных задач меньше, чем ядер, то да, создаем рабочих потоков по необходимости (переиспользуя их для вновь входящих запросов), используем блокирующий IO и радуемся жизни. Более того, если в пределах задач время IO операций сильно больше времени CPU, то с блокирующим IO можно хорошо жить, даже если число задач в десятки или даже в 100 раз больше, чем число ядер. Правде есть риск, что в какие-то моменты времени у нас будет возникать одновременно неспящих потоков больше, чем число ядер, что заставит систему их по кругу переключать. Если сильно больше — то на переключение между потоками будет тратиться заметное количество времени (ОС не знает, что эти переключения делать не нужно).
_>Но не всё так просто. В случае использования системных потоков и отдельных подсистем (типа UI) возникает проблема возврата данных в некий выделенный поток. У этой проблемы есть много разных решений с разной сложностью и удобством. Например в .net эту проблему довольно эффективно решает await. Существует полностью аналогичная реализация этого в C++ на базе Boost.Coroutine — обсуждалось подробно на этом форуме год назад. Кстати, лично мне эта техника не нравится (хотя именно я и продемонстрировал тогда пример реализации), т.к. на мой взгляд она вызывает путаницу в коде (канонический пример был с запуском скачивания из сети внутри обработчика кнопок и последующим выводом результата скачивания). Лично мне больше нравится модель акторов (причём по схеме 1 актор=1 системный поток). Естественно есть и ещё варианты (например продолжения и т.п.).
Без поддержки языка работать с продолжениями неудобно — будет лапша. Await внутри реализован через корутины, но это детали реализации. Вполне могло быть реализовано через продолжения, как в F# (Asynchronous Workflows). Интересует не "полностью аналогичная реализация", а аналогичная возможность — чтоб лапши небыло, но с масштабируемостью из коробки.
А чем с акторами проще?
_>2. Когда требуется небольшое число одновременных задач.
Когда требуется большое число одновременных задач?
_>В данном случае очевидно надо переходить к асинхронному IO. А вот механизм исполнения параллельных задач может быть очень разный: можно работать непосредственно на базе асинхронных колбэков (используя библиотеки типа libevent, libev или вообще руками), а можно использовать какую-то разновидность зелёных потоков, работающих поверх пула системных. Причём если говорить о зелёных потоках, то у них есть множество очень разных реализаций: _> — Это могут быть сопрограммы поверх пула системных. Причём опять же разделяются на: stackless (как в .net await или в примерах boost.asio) и stackfull (boost.coroutine). Насколько я понял именно применение последних в данном контексте тебя и интересует. Так вот фокус в том, что в данном случае они "просто работают". ))) Т.е. какой-то дополнительный код потребовался именно для реализации техники "возврата в спец. поток", а для просто реализации зелёных потоков поверх пула системных ничего дописывать и не надо — оно просто работает. Как собственно Евгений и продемонстрировал. Вот разве что реализацию семафора дописать.
Семафор с асинхронным wait-ом я ради красного словца привел (кстати, это Рихтер придумал и продал патент Майкрософту)) ).
Еще раз, меня в этой ветке интересует, чтоб масштабируемость по ядрам была и чтоб при этом код в лапшу не превращался. И да, я имею ввиду сервис, не UI.
_>а для просто реализации зелёных потоков поверх пула системных ничего дописывать и не надо — оно просто работает
Покажи?
_>- это могут быть акторы (уже более сложные, работающие поверх пула системных потоков). Тут конечно самый известный Эрланг, но и в C++ с этим не плохо. Мне например нравится библиотечка Theron.
Имхо, акторы хороши, когда модель приложения в виде асинхронно общающихся объектов, посылающих друг другу сообщения, является естественной для решаемой задачи. Неясно, нафиг они нужны для вышеупомянутого сервиса и для UI с кнопкой, по которой что-то асинхронно выкачивается. Можешь объяснить?
_>- встроенные в некоторые языки специфические реализации многозадачности _>- всякие велосипедные реализации именно зелёных потоков в чистом виде.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Вот слабо верится.
С верой в другую инстанцию.
НС>>Я словосочетание mixed mode для кого написал? Ничего переделывать не надо. ХГД>Если я в C++ коде кину std::runtime_error, как мне его в ASP ловить?
А зачем его в ASP ловить?
ХГД> Надо, например, в таких случая 500 выдавать с текстом из исключения. Ну и на некоторые типы исключений специальным образом реагировать — где-то 403 выдавать, где-то редиректы делать и т.п.
Перехватывай в C++/CLI, заворачивай в HttpException с нужным кодом. Все равно код перехвата тебе писать руками, хоть в С++, хоть в C++/CLI.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Какие keyword'ы поискать по теме?
Тема довольно обширная. Какие кейворды? Ну попробуй code access security.
НС>>Есть соотвествующие метки контекста. EP>Метки кто расставляет?
Программист.
НС>>Тут все совсем просто — вылет исключения возможен всегда. Только какое это имеет отношение к безопасности? CLR не С++, неперехваченное исключение память не портит. EP>С исключениями как раз в C#/Java проблем больше, using'и/try-with-resources это полумера, с транзитивностью распространения is-a-resource никак не помогает. Тема уже не раз обсуждалась.
Не знаю что и где обсуждалось. Ты здесь ответь — какие проблемы у дотнета и джавы с исключениями в контексте безопасности?
EP>Но суть в другом — если код не готов к исключению, то оно может поломать инварианты
А надо так писать, чтобы инварианты вообще нельзя было поломать. В любом случае, это не имеет отношения к механизмам обеспечения безопасности кода.
EP>А к безопасности это имеет самое прямое отношение — большинство проблем с безопасностью происходят от нарушения предусловий/инвариантов
Бездоказательно. Из того что вижу я — главный источник серьезных проблем это переполнение буфера и прочие варианты прохода по памяти. Либо ошибки в алгоритмах.
Здравствуйте, Anton Batenev, Вы писали:
AB>Я предлагаю делегировать это тем, кто этим занимается профессионально и имеет соответствующие ресурсы безотносительно половой и прочей принадлежности — получается быстрее, дешевле и надежнее.
Оппа, отдельный выделенный сервер у дяди стоит дешевле, чем оплата за потребляемое им электричество? о0
НС>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно? S>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?
ты профилировал перед или чутьё подсказало, что std::string достаточно быстр?
ХГД>>Чего готовое? У меня, к примеру, к разным плюсовым объектам разные юзеры имеют разные уровни доступа.
НС>А аутентификация как? basic и хватит?
Разумеется. Внутри SSL не пофиг ли как пароль гнать — открытым текстом или чего-нибудь с ним мутить? А без SSL надежную схему все равно не реализовать.
ХГД>>>> Да и вообще она например 8 лет назад сделана для нейтив клиентов. НС>>>А для серверов? ХГД>>Ась? Каких серверов?
НС>Серверную часть аутентификации как, тоже руками?
Конечно. Если надо жить в домене, то через LDAP или LogonUser, на выбор (там на самом деле еще варианты с хранением виндовых паролей в сервере и имперсонацией-делегированием), если stand-alone — то проверка пароля через SRP (потому что через него работают нейтив клиенты).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Какие keyword'ы поискать по теме? НС>Тема довольно обширная. Какие кейворды? Ну попробуй code access security.
Я обрисовал задачу, ты сказал что это уже есть в CLR — вот и покажи где именно.
НС>>>Есть соотвествующие метки контекста. EP>>Метки кто расставляет? НС>Программист.
Как именно это происходит?
Должно быть примерно так: программист пишет свою функцию и вызывает другую, на которой в том числе написано "может взорваться", на своей функции он обязан написать тоже самое, если не напишет то компилятор (или среда, не суть) — должен выдать ошибку.
НС>>>Тут все совсем просто — вылет исключения возможен всегда. Только какое это имеет отношение к безопасности? CLR не С++, неперехваченное исключение память не портит. EP>>С исключениями как раз в C#/Java проблем больше, using'и/try-with-resources это полумера, с транзитивностью распространения is-a-resource никак не помогает. Тема уже не раз обсуждалась. НС>Не знаю что и где обсуждалось.
Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс.
НС>Ты здесь ответь — какие проблемы у дотнета и джавы с исключениями в контексте безопасности?
Поломка инвариантов.
EP>>Но суть в другом — если код не готов к исключению, то оно может поломать инварианты НС>А надо так писать, чтобы инварианты вообще нельзя было поломать.
Ха! 90% проблем с безопасностью решил одним росчерком пера!
Сферический пример:
Есть две полки, на одной из них стоят стаканы. Нужно сделать так, чтобы стаканы оказались на другой полке. У системы инвариант: все стаканы на одной полке, либо на другой, причём "целые".
Ты начинаешь их перекладывать, и рука где-то в середине процесса "кидает исключение", так как не может достичь своих постусловий — стакан разбит (no exception safety), инвариант поломан безвозвратно. Даже если представить что отказ произошёл без повреждения стакана(strong exception safety), то что делать дальше? На какую полку ты бы не пытался переложить оставшиеся части — рука опять "кидает исключение", вернуться ни в одно из стабильных состояний невозможно, инварианты поломаны.
Как вариант можно купить новые стаканы, поставить на пустую полку, а с другой куда-нибудь убрать, но это дорого, и не всегда возможно.
Всё что нужно для дешёвого решения — рука не должна бросать исключение (no-throw guarantee). Соответственно можно просто положиться на авось, что мол "раньше там не было исключения", а можно сделать систему которая даст 100% гарантию, что никакого исключения там не будет.
НС>В любом случае, это не имеет отношения к механизмам обеспечения безопасности кода.
Это создаёт дополнительные угрозы безопасности.
EP>>А к безопасности это имеет самое прямое отношение — большинство проблем с безопасностью происходят от нарушения предусловий/инвариантов НС>Бездоказательно. Из того что вижу я — главный источник серьезных проблем это переполнение буфера и прочие варианты прохода по памяти. Либо ошибки в алгоритмах.
Исключения это конкретный пример — если для исключений подобного контроля нет, ок, то покажи хотя бы для каких аспектов он есть.
Здравствуйте, Sheridan, Вы писали:
S> AB>Я предлагаю делегировать это тем, кто этим занимается профессионально и имеет соответствующие ресурсы безотносительно половой и прочей принадлежности — получается быстрее, дешевле и надежнее. S> Оппа, отдельный выделенный сервер у дяди стоит дешевле, чем оплата за потребляемое им электричество? о0
Дешевле нежели покупка сервера, расходы на ЗИП, организация и расходы на канал, зарплата тебе, пока ты все это выпрашивал. Потерянные же полгода в некоторых случаях для бизнеса могут быть вообще "бесценны" (хороша ложка к обеду).
Конкретно в контексте "WP на коленке" для которого достаточно shared или виртуалки это бы обошлось в ~400 руб/мес, или 2400 за те самые пол года — один раз сходить в кафешку. При этом за эти деньги получаем все прелести профессионального хостинга типа резервного питания, сети, замены оборудования/комплектующих, поддержки 24/7 и т.д.
ХГД>>Вот слабо верится.
НС>С верой в другую инстанцию.
Ладно, переформулирую — да ты гонишь. Или, если хочешь, твои голословные утверждения нуждаются в доказательствах.
НС>>>Я словосочетание mixed mode для кого написал? Ничего переделывать не надо. ХГД>>Если я в C++ коде кину std::runtime_error, как мне его в ASP ловить?
НС>А зачем его в ASP ловить?
А что, можно не ловить? И че тогда будет?
ХГД>> Надо, например, в таких случая 500 выдавать с текстом из исключения. Ну и на некоторые типы исключений специальным образом реагировать — где-то 403 выдавать, где-то редиректы делать и т.п.
НС>Перехватывай в C++/CLI, заворачивай в HttpException с нужным кодом. Все равно код перехвата тебе писать руками, хоть в С++, хоть в C++/CLI.
Ну то есть это надо будет делать не в 1 месте, как сейчас, а в 100. Нафиг-нафиг.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>А что, можно не ловить? И че тогда будет?
Ты любитель С++, вот и расскажи что будет.
НС>>Перехватывай в C++/CLI, заворачивай в HttpException с нужным кодом. Все равно код перехвата тебе писать руками, хоть в С++, хоть в C++/CLI. ХГД>Ну то есть это надо будет делать не в 1 месте, как сейчас, а в 100.
С какой стати? С++ не умеет написать один раз код, перехватывающий исключения и потом его везде использовать?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Программист. EP>Как именно это происходит?
Оператор у языка такой специальный есть.
EP>Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс.
Какая связь IDisposable и декларации исключений?
EP>Поломка инвариантов.
Это не проблема исключений.
EP>Сферический пример: EP>Есть две полки, на одной из них стоят стаканы. Нужно сделать так, чтобы стаканы оказались на другой полке. У системы инвариант: все стаканы на одной полке, либо на другой, причём "целые". EP>Ты начинаешь их перекладывать
Ну вот, тут уже неправильно. Правильно — создать новую полку сразу со стаканами, передав их в конструктор, и заменить вторую полку на новую. И я не вижу в этом никакой разницы между С++ и управляемыми языками.
EP>Исключения это конкретный пример
Не, это ты тут гипотетические угрозы расписываешь. А реальная проблема из-за этого, она насколько часто в природе встречается?
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Как именно это происходит? НС>Оператор у языка такой специальный есть.
Какой?
EP>>Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс. НС>Какая связь IDisposable и декларации исключений?
Я показываю опасность исключений в C#, по сравнению с C++, раз уж ты начал сравнивать
НС>CLR не С++, неперехваченное исключение память не портит.
EP>>Поломка инвариантов. НС>Это не проблема исключений.
Вероятность поломки инвариантов в системе из-за внезапно вылетевшего исключения, либо некорректно обработанного — это проблема сопутствующая использованию исключений
EP>>Сферический пример: EP>>Есть две полки, на одной из них стоят стаканы. Нужно сделать так, чтобы стаканы оказались на другой полке. У системы инвариант: все стаканы на одной полке, либо на другой, причём "целые". EP>>Ты начинаешь их перекладывать НС>Ну вот, тут уже неправильно. Правильно — создать новую полку сразу со стаканами, передав их в конструктор, и заменить вторую полку на новую. И я не вижу в этом никакой разницы между С++ и управляемыми языками.
Это неэффективное использование ресурсов, к тому же не всегда возможное.
Конкретный пример: есть 10GiB файлов, их нужно переместить на новое место в пределах файловой системы, общий размер которой 11GiB. Инвариант — файлы либо на новом месте, либо на старом. Скопировать на новое место, а потом удалить в старом, очевидно, не получится.
EP>>Исключения это конкретный пример НС>Не, это ты тут гипотетические угрозы расписываешь. А реальная проблема из-за этого, она насколько часто в природе встречается?
Ignoring an exception can cause the program to overlook unexpected states and conditions.
When an exception is thrown and not caught, the process has given up an opportunity to decide if a given failure or event is worth a change in execution.
Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.
Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс.
Не совсем. Если объект инжектится и сохраняется в поле, то и диспозить его не нужно, за редким исключением.
Вобщем, не часто возникает такая проблема, особенно при использовании DI-контейнеров.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Оператор у языка такой специальный есть. EP>Какой?
checked и unchecked. И еще ключик у компилятора для всей сборки.
EP>>>Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс. НС>>Какая связь IDisposable и декларации исключений? EP>Я показываю опасность исключений в C#, по сравнению с C++, раз уж ты начал сравнивать
И при чем тут IDisposable?
EP>Это неэффективное использование ресурсов
А это еще неизвестно. Иногда новая полка эффективнее записи в старую со всем гемороем в виде транзакций и их изоляции. А если еще и процессоров много ...
EP>Конкретный пример: есть 10GiB файлов, их нужно переместить на новое место в пределах файловой системы,
Это уже вопрос транзакций в ФС, исключения в языках тут точно не в тему. Никакая суперобработка исключений не спасет тебя от сшибания процесса.
EP>Ignoring an exception can cause the program to overlook unexpected states and conditions.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Оператор у языка такой специальный есть. EP>>Какой? НС>checked и unchecked. И еще ключик у компилятора для всей сборки.
Насколько я понял, это всего лишь включение/выключение runtime проверок.
Вопрос был про то — как определить что вызываемый метод использует небезопасные фичи. Реальные примеры из Haskell'я я привёл — монады IO и Exceptional, меня интересуют аналоги (в плане безопасности и надёжности).
EP>>>>Добавление IDisposable объекта в поле какого либо класса, заставляет транзитивно менять весь код, который напрямую или косвенно использует этот класс. НС>>>Какая связь IDisposable и декларации исключений? EP>>Я показываю опасность исключений в C#, по сравнению с C++, раз уж ты начал сравнивать НС>И при чем тут IDisposable?
Было:
class Foo
{
// ...
};
Foo используется в N местах (включая транзитивные зависимости).
Стало:
class Foo
{
Resource deficit;
// ...
};
В случае C# — придётся просмотреть все N мест (и возможно добавить недостающий код). Соответственно есть вероятность что-то пропустить.
EP>>Это неэффективное использование ресурсов НС>А это еще неизвестно. Иногда новая полка эффективнее записи в старую со всем гемороем в виде транзакций и их изоляции. А если еще и процессоров много ... НС>Это уже вопрос транзакций в ФС, исключения в языках тут точно не в тему.
Это вполне жизненный пример требующий от операции иметь no-throw guarantee, чтобы вызывающий код смог иметь strong exception safety (транзакционность).
Соответственно это требование неплохо было бы отметить кодом, да так чтобы его нарушение смогло быть определенно на этапе компиляции или хотя бы сборки.
EP>>Ignoring an exception can cause the program to overlook unexpected states and conditions. НС>Это опять теория.
Допустим с исключениями нет никак потенциальных проблем, ОК. Ты сказал
НС>Вы сейчас как раз CLR и изобретаете.
покажи пример подобного механизма не для исключений.
