Здравствуйте, Mamut, Вы писали:

M>Эээ чо?
У тебя после join десяти тасков появляется конструкция из десяти результатов, каждый из которых — либо win либо fail. Тебе не надо для этого изобретать самодельные ThrownExceptionsCollection. Просто любой код, который собирается потреблять результаты, должен придумать стратегию. Например, найти первый же сбой и вернуть его наверх как результат.
Или показать диалог с errorsFound, сохранив успешные результаты. Всё зависит от конкретной задачи, но в любом случае есть все необходимые инструменты — свёртки списков и прочее.

Здравствуйте, Mamut, Вы писали:



M>У Apple'а есть Objective-C, в который пытались впихнуть GC, и есть Swift, который должен быть совместимым со всем кодом, написанным на этом самом Objective-C. Вот тут да, возможно и есть задержка в 0.05 секунды банально из-за того, что нельзя натянуть GC на Objective-C.
Почему нельзя, если натягивали уже, и стянули затем?

Здравствуйте, VladD2, Вы писали:
VD>Дык, все ненавистники исключений обычно и имеют опыт их использования исключительно на С++. Возможно, если бы авторы того же Раста по пользовались бы языками где исключения реализованы качественно, у них и не возникло бы желания возвращаться в прошлые века и городить сахар над кодами возврата.
А можно посмотреть на пример языка, где исключения реализованы качественно?
Скажем, в C# они спроектированы явно коряво. Они плохо работают с многопоточностью (http://ericlippert.com/2009/03/06/locks-and-exceptions-do-not-mix/), с модными фишками типа iterator block (http://blogs.msdn.com/b/ericlippert/archive/2009/07/23/iterator-blocks-part-five-push-vs-pull.aspx), и наверняка ещё в паре мест, о которых я не знаю.

Здравствуйте, Sinclair, Вы писали:

S>Скажем, в C# они спроектированы явно коряво. Они плохо работают с многопоточностью (http://ericlippert.com/2009/03/06/locks-and-exceptions-do-not-mix/), с модными фишками типа iterator block (http://blogs.msdn.com/b/ericlippert/archive/2009/07/23/iterator-blocks-part-five-push-vs-pull.aspx), и наверняка ещё в паре мест, о которых я не знаю.

Это стандартные проблемы для любых короутин/акторов, они не уникальны для шарпа.
Проще всего они решаются для односторонних push-итераторов/обсерверов. Т.е. для дотнета — для await и rx. По большому счёту, единственная неприятность: в стек пролазят детали реализации, но студия позволяет их скрыть без особых на то проблем.
Разумеется, за простоту приходится расплачиваться — или лёгкой сфероконичностью RX, или не совсем очевидными нюансами для await.

И да, когда ты пишешь про проблемы при сборе результатов, то на самом деле проблемы начинаются на несколько шагов выше, при запуске асинхронного кода. Потому что для асинхронного кода по определению нет никаких гарантий, что вызывающий код получит результат за обозримое время. Всё остальное — это уже следствия.
Конечно фреймворк может до определённой степени сохранять иллюзию последовательного выполнения, но она рано или поздно обломится на получении результатов/исключений или на дедлоке из-за блокирующего ожидания (например, в ui-потоке).
Наконец, при попытке не спрятать асинхронность, а дать возможность явно расписывать async codeflow средствами языка мы упрёмся в фундаментальную CAP theorem. Т.е. как ни извращайся, проблемы асинхронности никуда не денутся. И вместо языка общего назначения получатся экзоты типа эрланга/MS Orleans/Cω со своими прелестями и ограничениями.

M>>Эээ чо?
S>У тебя после join десяти тасков появляется конструкция из десяти результатов, каждый из которых — либо win либо fail. Тебе не надо для этого изобретать самодельные ThrownExceptionsCollection. Просто любой код, который собирается потреблять результаты, должен придумать стратегию. Например, найти первый же сбой и вернуть его наверх как результат.
S>Или показать диалог с errorsFound, сохранив успешные результаты. Всё зависит от конкретной задачи, но в любом случае есть все необходимые инструменты — свёртки списков и прочее.

Ничем не отличается от exception'ов Пример кода из самого Раста я приводил. Там пятиуровневая конструкция, из недр которой наверх возвращается некий ErrorReport. Чем он отличается от самодельного ThrownExceptionsCollection? Да ничем

Здравствуйте, Sinclair, Вы писали:

S>А можно посмотреть на пример языка, где исключения реализованы качественно?
S>Скажем, в C# они спроектированы явно коряво. Они плохо работают с многопоточностью (http://ericlippert.com/2009/03/06/locks-and-exceptions-do-not-mix/),

Ты читал что там написано?

so we’ve fixed that for C# 4.0.

Баг не в исключениях, а в генерации кода была. Да и скорее багом является наличие thread abort exception, который может случиться между случайными инструкциями.

S>с модными фишками типа iterator block (http://blogs.msdn.com/b/ericlippert/archive/2009/07/23/iterator-blocks-part-five-push-vs-pull.aspx), и наверняка ещё в паре мест, о которых я не знаю.

Подумай лучше как с итераторами коды возвратов использовать.

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

M>>У Apple'а есть Objective-C, в который пытались впихнуть GC, и есть Swift, который должен быть совместимым со всем кодом, написанным на этом самом Objective-C. Вот тут да, возможно и есть задержка в 0.05 секунды банально из-за того, что нельзя натянуть GC на Objective-C.
_>Почему нельзя, если натягивали уже, и стянули затем?

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

Вполне возможно, что можно было бы и допилить, но в 2007-м подоспел айфон, и времени пилить GC не было, когда рядом был быстрый подсчет ссылок, а SDK надо было выпускать «ужепрямосейчас».

Здравствуйте, VladD2, Вы писали:

VD>Нет, батенька, ты путаешь основную логику приложения и логику обработки исключительных ситуаций, которая к ней отношения не имеет. Весь смысл в том, что в нормальных условиях твоя программа будет работать вообще без обработки исключений или кодов возвратов. В языке с исключениями ты и пишешь весь код так, как-будто ошибок быть не может. В языке же с кодами возвратов ты тратишь тучу времени на поддержание инфраструктуры обработки ошибок, а значит сложность в твоих программах нарастает быстрее и ты потратишь значительно больше усилий на создание аналогичной программы, чем я.
А в реальности — код обработки ошибки её молча душит, иногда с комментарием (по мотивам: Re[3]: chrome mailto limit

Автор: fddima
Дата: 19.05.15

(смотреть конец функции)).

Здравствуйте, AlexRK, Вы писали:

M>>В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, рпидется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>?
ARK>Ну так пусть функция возвращает нужное значение, в чем проблема? Ах, внутри файл читается? Тогда будьте добры отреагировать на потенциальный сбой.
ARK>Не хотите? Используйте другие языки, никто не против.
ARK>Лично мне нравится подход Rust/Swift.
Как минимум, проблема в том, что код который может бросить исключение или ошибку — может вызываться косвенно, и что именно это будет за код — заранее не известно.
При чём обработка ошибки — не ответственность вызывающего кода.
Однако, не забудь, что разработчики обоих частей кода не знают друг о друге, и о возможных ошибках.

        static int Main(string[] args)
        {
            var fileNames = new string[] { "header.js", "library.core.js",  "library.ext.js", "footer.js" };
            try
            {
                var content = fileNames
                    .Select(x => "// " + x + "\n" + File.ReadAllText(x) + "\n") // лямбда - тот самый код
                    .Aggregate((current, next) => current + next);
                return 0;
            }
            catch (Exception ex) // а тут нам вообще пофиг, что упало, но должно быть записано в лог, да ещё со стек-трейсом, что бы было понятно, кто виноват
            {
                Console.WriteLine("Error! {0}", ex.Message);
                return 1;
            }
        }

Здравствуйте, VladD2, Вы писали:

VD>Дык, все ненавистники исключений обычно и имеют опыт их использования исключительно на С++. Возможно, если бы авторы того же Раста по пользовались бы языками где исключения реализованы качественно, у них и не возникло бы желания возвращаться в прошлые века и городить сахар над кодами возврата.

Несколько раз пролистал ветку и так и не понял, что такое хорошая и что такое плохая реализация исключения. Чем исключение в C# лучше исключения в C++? И почему кто-то может ненавидеть исключения базируясь на плюсовом опыте? С ними же там все в норме, а вот то, что их в вышеупомянутом Rust нет – лажа невероятная

Здравствуйте, kaa.python, Вы писали:

KP>Несколько раз пролистал ветку и так и не понял, что такое хорошая и что такое плохая реализация исключения. Чем исключение в C# лучше исключения в C++? И почему кто-то может ненавидеть исключения базируясь на плюсовом опыте? С ними же там все в норме, а вот то, что их в вышеупомянутом Rust нет – лажа невероятная
В Расте пока думают как их добавить. Вроде бы есть консенсус, что от них в итоге никуда не деться.

Здравствуйте, VladD2, Вы писали:

VD>Ты читал что там написано?
Да, читал.
VD>

VD>so we’ve fixed that for C# 4.0.

А ты — нет. Потому, что дальше там написано:

So everything is good now, right?
Sadly, no. It’s consistently bad now

VD>Основная проблема шарпа в том, что он развивается эвалюционно. В его дизайн новые фичи просто не закладывались. В новом языке проблемы можно обойти.
Не вижу ответа на свой вопрос.

Здравствуйте, kaa.python, Вы писали:

KP>Несколько раз пролистал ветку и так и не понял, что такое хорошая и что такое плохая реализация исключения. Чем исключение в C# лучше исключения в C++? И почему кто-то может ненавидеть исключения базируясь на плюсовом опыте?
В С++ основная дупа — в том, что нет сборки мусора, а на динамически созданные объекты раскрутка стека не влияет.
Поэтому ты на ровном месте получаешь утечку:

CConnection * pConnection = null;
try 
{
  auto tmp = new CConnection(...);
  tmp.setProxy(...); 
  tmp.attachCertStore(...);
  pConnection = tmp;
} catch(...)
{
   // оппа! 
}

Здравствуйте, Sinclair, Вы писали:

S>В С++ основная дупа — в том, что нет сборки мусора, а на динамически созданные объекты раскрутка стека не влияет.
S>Поэтому ты на ровном месте получаешь утечку:

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

Здравствуйте, kaa.python, Вы писали:

KP>Ну вообще-то, в 21 веке, более-менее квалифицированные C++ программисты такого трэша не пишут и пользуются умными указателями
Ну, поскольку невозможно запретить программистам быть неквалифицированными, или использовать ключевое слово auto, или потоку прерываться между вызовом конструктора объекта и вызовом конструктора умного указателя, этот аргумент выглядит не очень убедительным.
KP>Я правильно понимаю, что это единственная проблема C++ исключений?
Ну, Влад наверняка знает про другие проблемы. Я написал про то, про что знаю я.

Здравствуйте, Sinclair, Вы писали:

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

и это приводит к...?

Сам на С++ пишу редко (но раньше, до стандарта 11, писал много), так что если в каких-то пунктах ошибаюсь или отстал от жизни то поправьте плиз.

KP>Ну вообще-то, в 21 веке, более-менее квалифицированные C++ программисты такого трэша не пишут и пользуются умными указателями
То что умные указатели так прижились, это имхо не достижение а косяк языка. Со стороны других языков эти умные указатели видятся таким кусочком GC кишками наружу с постоянным шумом в сорцах и непредсказуемом оверхэде в исполняемом коде.

KP>Я правильно понимаю, что это единственная проблема C++ исключений?
То что не нравилось мне:

1) нет finally, поэтому основная идиома "прибрать за собой в любом случае, было исключение или нет", превращается либо в двойные телодвижения, либо в надежду на RAII. Про макросы и библиотеки эмулирующие finally я вкурсе, не устраивают.
2) можно кидать и ловить любую ерунду, с которой потом фиг поймёшь что делать. Вместе с другими зажравшимися программистами из мира интерпретаторов я уже привык к удобному объекту "исключение", с полями, методами, вот этим всем.
3) разные команды используют разные базовые классы для исключений, и ни в стандарте ни в популярных либах нету самого главного — стэк трэйса. В результате на разных платформах и в разных компиляторах нужен разный код для сбора стэктрэйса, котрый вроде как нужно вызывать именно в методе где летело само исключение, потом уже поздно. На MSVC точно было именно так, на GCC чуть легче, на Intel не помню.
4) как следствие 3 большинство глобальных перехватов исключений сводится к "записать memory dump при вылете". В том же C# до мемори дампа дело доходит гораздо реже чем в C++.
5) возникают сложные моменты если исключения летят в конструкторах/деструкторах. Для собеседований оно даже хорошо, для надёжной работы не очень.
6) хотелось бы больше помощи от компилятора/IDE в деле разбора чего как и откуда в принципе может вылететь. Этого хотелось бы от всех компиляторов, но C++ в этом чуть впереди, так как появился noexcept.

Здравствуйте, fddima, Вы писали:

F> Как минимум, проблема в том, что код который может бросить исключение или ошибку — может вызываться косвенно, и что именно это будет за код — заранее не известно.
F> При чём обработка ошибки — не ответственность вызывающего кода.
F> Однако, не забудь, что разработчики обоих частей кода не знают друг о друге, и о возможных ошибках.

Да, это распространенное мнение. В нем есть свой резон.

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

TD;LR. Я не считаю описанный вами способ корректным. Подходящим на практике в каких-то случаях (может быть, даже в большом количестве случаев) — может быть. Корректным — нет.

Здравствуйте, kaa.python, Вы писали:

KP>и это приводит к...?
Нуу... к тому же самому — утечке, нет?

Здравствуйте, hi_octane, Вы писали:

_>Сам на С++ пишу редко (но раньше, до стандарта 11, писал много), так что если в каких-то пунктах ошибаюсь или отстал от жизни то поправьте плиз.

_>То что не нравилось мне:

_>1) нет finally, поэтому основная идиома "прибрать за собой в любом случае, было исключение или нет", превращается либо в двойные телодвижения, либо в надежду на RAII. Про макросы и библиотеки эмулирующие finally я вкурсе, не устраивают.

Что значит "надежда на RAII"? Это все равно что "надежда на то, что sin(x) вернет синус, а не косинус"
RAII — это же не финализаторы в управляемых языках, которые хз когда позовутся и позовутся ли вообще.
Тут все гарантировано самим языком, безо всяких надежд.

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

Все вменяемые разработчики бросают производные от std::exception аж с 98 года.

_>3) разные команды используют разные базовые классы для исключений, и ни в стандарте ни в популярных либах нету самого главного — стэк трэйса. В результате на разных платформах и в разных компиляторах нужен разный код для сбора стэктрэйса, котрый вроде как нужно вызывать именно в методе где летело само исключение, потом уже поздно. На MSVC точно было именно так, на GCC чуть легче, на Intel не помню.

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

_>4) как следствие 3 большинство глобальных перехватов исключений сводится к "записать memory dump при вылете". В том же C# до мемори дампа дело доходит гораздо реже чем в C++.

Я у себя такого большинства не наблюдаю. Очень мало когда дело доходит именно до глобальных обработчиков, и даже если доходит, то в самом объекте исключения вся информация уже будет.

_>5) возникают сложные моменты если исключения летят в конструкторах/деструкторах. Для собеседований оно даже хорошо, для надёжной работы не очень.

То ли дело возвращаемые значения. Так и вижу, как из конструктора/деструктора возвращаются коды ошибок
Как раз исключения в конструкторах гарантируют, что объект не будет создан в кривом состоянии.
При этом RAII прибьет то, что успело создаться к моменту вылета исключения.

_>6) хотелось бы больше помощи от компилятора/IDE в деле разбора чего как и откуда в принципе может вылететь. Этого хотелось бы от всех компиляторов, но C++ в этом чуть впереди, так как появился noexcept.

да, noexcept рулит. Раньше приходилось либо атрибутами пользоваться, либо вообще комментариями (что, в принципе, как-то работало — у меня был специальный doxygen-макрос на эту тему)

You will always get what you always got
  If you always do  what you always did