. VYR> либо занимайся ООП при оработке ошибок (даже вложеную цепочку можно построить) VYR>либо гадай на каком этапе была ошибка, что в try...catch невозможно узнать без костылей...
Исключения типизированные, есть stack trace. Чего еще не хватает?
Если это отсылка к C++, то преимущества заканчиваются там довольно быстро как только объекты становятся членами класса (ссылками). Да, проблема, решается с помощью всяческих примитивов, но обилие их количества и семантики едва ли можно назвать выигрышем в чистом виде.
. VYR>> либо занимайся ООП при оработке ошибок (даже вложеную цепочку можно построить) VYR>>либо гадай на каком этапе была ошибка, что в try...catch невозможно узнать без костылей...
TG>Исключения типизированные, есть stack trace. Чего еще не хватает?
вот имено стек вызовов а не ошибок.
а где в функуии если вложеные функции одинаковы — облом
Здравствуйте, Mystic Artifact, Вы писали:
MA>Если это отсылка к C++, то преимущества заканчиваются там довольно быстро как только объекты становятся членами класса (ссылками).
О чём ты?
class Widget
{
File x;
...
};
MA>Да, проблема, решается с помощью всяческих примитивов, но обилие их количества и семантики едва ли можно назвать выигрышем в чистом виде.
То о смарт-поинтерах? Базовых всего два, если лень и много ресурсов — можно вообще знать только один.
В большинстве случаев они не нужны — ну то есть если взять места в программе где создаются объекты, и посчитать в скольких случаях нужны какие-либо смарт-поинтеры — то окажется что это доли процента от общего числа, а в подавляющем большинстве случаев происходит так как в Widget выше
Здравствуйте, vvv848165@ya.ru, Вы писали:
TG>>Исключения типизированные, есть stack trace. Чего еще не хватает? VYR>вот имено стек вызовов а не ошибок. VYR>а где в функуии если вложеные функции одинаковы — облом
Честно говоря, по моему мнению (не везде это так), в 99% достаточно знать имя файла/номер строки, где сработал ассерт или выброшена ошибка. Наличие стэктрэйса в дотнете это вообще как чит. Если этой информации не достаточно для устранения ошибки сразу — то вероятнее всего, в любом случае понадобится воспроизведение и/или дебаг сессия. Создание автоматических дампов памяти не ко всему применим и не на все вопросы отвечают. Как бывают и другие особенности в проектах, где это вообще всё бесполезный груз.
Что бы стек вызовов был прозрачным — надо научиться делать "rethrow" правильно.
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Может подскажите как меньшими силами обходит похожие грабли ???
Сделать обработку исключения там, где ты можешь его обработать или не обрабатывать совсем. Ловить исключение и писать в лог это неверно.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>О чём ты? EP>
EP>class Widget
EP>{
EP> File x;
EP>...
EP>};
EP>
Это же аггрегация вроде. Я о полях вида ptr<T> разного толка. Такое тоже имеет место быть, но я такое вижу крайне редко (ну кроме случаев когда вместо File простые структуры).
EP>То о смарт-поинтерах? Базовых всего два, если лень и много ресурсов — можно вообще знать только один. EP>В большинстве случаев они не нужны — ну то есть если взять места в программе где создаются объекты, и посчитать в скольких случаях нужны какие-либо смарт-поинтеры — то окажется что это доли процента от общего числа, а в подавляющем большинстве случаев происходит так как в Widget выше
Ну, я вижу скорее обратное: почти всё завязано на какие-нибудь обертки. это от объектов-прокси IPC, параметры-колбэки и т.п. И их не всего два, а в каждом огороде свой. (Хотя всё и сдвинулось в сторону стандартов — но стандарт не может сдвинуть специального вида ссылки, к примеру если это внешняя GC ссылка, которая обязательно обернута в свой смарт поинтер.)
Плюс это всё сдобрено в перемешку с std::move, который нужно или не нужно применять приходится решать в конкретном месте, не потому что лень знать, а потому что из сигнатуры не всегда ясно, чего ожидают от метода.
На фоне всех этих трюков в C++, ручное управление ресурсами в C#, лично для меня не выглядит чем-то более сложным.
Я понимаю, что это всё довольно субьективно, и я не отрицаю, что объективно механизмов в C++ больше, они мощнее и при должном упорстве получается красиво. Но субьективизм...
а почему из finally аргумент Exception не доступен???
А ведь нужен иногда бывает (например чтобы посмотреть какая ошибка и не тргать лишние обьекты)
прям ...
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>а почему из finally аргумент Exception не доступен??? VYR>А ведь нужен иногда бывает (например чтобы посмотреть какая ошибка и не тргать лишние обьекты) VYR>прям ...
Потому что исключение должно обрабатываться в блоке catch. А в finally код обрабатывается вне зависимости от того было исключение или нет.
Здравствуйте, Maniacal, Вы писали:
M>Потому что исключение должно обрабатываться в блоке catch. А в finally код обрабатывается вне зависимости от того было исключение или нет.
что дополнительно неудобно...
вспомнил первый курс универа — тогда про него читал (C++Builder) и удивлялся как он так работает...
с тех пор почти ничего не поменялось...
для состояний внутри класса (даже если не конечным автоматом) — это просто кашмар как неудобно...
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>для состояний внутри класса (даже если не конечным автоматом) — это просто кашмар как неудобно...
Потому исключение и называется исключением. Не предусмотренная алгоритмом внештатная ситуация.
Это больше 99% случаев.
MA>Я о полях вида ptr<T> разного толка.
А это соответственно меньше 1%.
MA>Такое тоже имеет место быть, но я такое вижу крайне редко
Это очень странно, ибо является вариантом по-умолчанию.
MA>(ну кроме случаев когда вместо File простые структуры).
Ну вот File как раз таким образом используется прямо влёт. В чём проблема-то?
EP>>В большинстве случаев они не нужны — ну то есть если взять места в программе где создаются объекты, и посчитать в скольких случаях нужны какие-либо смарт-поинтеры — то окажется что это доли процента от общего числа, а в подавляющем большинстве случаев происходит так как в Widget выше MA> Ну, я вижу скорее обратное: почти всё завязано на какие-нибудь обертки. это от объектов-прокси IPC, параметры-колбэки и т.п.
Ну вот например std::vector или std::function — ты к чему относишь? К смарт-поинтерам?
MA>Плюс это всё сдобрено в перемешку с std::move, который нужно или не нужно применять приходится решать в конкретном месте, не потому что лень знать
Обычно если забыть move, будет либо ошибка компиляции, либо лишняя копия.
MA>а потому что из сигнатуры не всегда ясно, чего ожидают от метода.
Пример в студию.
MA>На фоне всех этих трюков в C++, ручное управление ресурсами в C#, лично для меня не выглядит чем-то более сложным.
Все эти "трюки" — два притопа, три прихлопа, и не нужно от забора и до обеда вручную управлять ресурсами.
MA>Я понимаю, что это всё довольно субьективно, и я не отрицаю, что объективно механизмов в C++ больше, они мощнее и при должном упорстве получается красиво. Но субьективизм...
Фишка в том что не просто красиво, а ещё и просто, а-ля class Widget{ File x; ... };.
Проблема обычно в том, что действительно есть код где совершенно необоснованное засилье ptr<T>, буквально на ровном месте. Обычно так происходит когда кто-то переходит с управляемых языков, и начинает везде лепить привычные new, потом задалбывается управлять вручную, ещё и огребает проблем с exception safety прям как ТС, и узнаёт про спасительные смарт поинтеры — с этого момента всё и оборачивается в ptr<T>.
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>Еслиб исключений небыло а только возвращались бы коды ошибок — то было бы подругому...
Посмотри как это "по другому" в Go происходит. Мягко говоря, борода из обработчиков ошибок там длинее кода основного потока исполнения.
VYR>и борода былабы меньше и писалась она бы в нужных местах...
Ошибаешься.
Здравствуйте, vvv848165@ya.ru, Вы писали:
VYR>а почему из finally аргумент Exception не доступен??? VYR>А ведь нужен иногда бывает (например чтобы посмотреть какая ошибка и не тргать лишние обьекты) VYR>прям …
Если хочешь в finally смотреть Exception то создай переменную вне блока try и устанавливать в catch.
finally хорош тем, что он выполняется и после return, что иногда удобно, когда уже правишь чей то год с кучей return
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это больше 99% случаев. MA>>Я о полях вида ptr<T> разного толка. EP>А это соответственно меньше 1%.
Ну ты просто не можешь аггрегировать объекты которыми не владеешь. Статистики у меня нет. Если ты получил смарт-поинтер — то с ним и живёшь.
EP>>>В большинстве случаев они не нужны — ну то есть если взять места в программе где создаются объекты, и посчитать в скольких случаях нужны какие-либо смарт-поинтеры — то окажется что это доли процента от общего числа, а в подавляющем большинстве случаев происходит так как в Widget выше MA>> Ну, я вижу скорее обратное: почти всё завязано на какие-нибудь обертки. это от объектов-прокси IPC, параметры-колбэки и т.п. EP>Ну вот например std::vector или std::function — ты к чему относишь? К смарт-поинтерам?
Не понимаю к чему вопрос. Нет, под смарт-поинтерами я понимаю типы, которые так или иначе оборачивают указатели на объекты наделяя их порою самыми невообразимыми свойствами.
MA>>Плюс это всё сдобрено в перемешку с std::move, который нужно или не нужно применять приходится решать в конкретном месте, не потому что лень знать EP>Обычно если забыть move, будет либо ошибка компиляции, либо лишняя копия. MA>>а потому что из сигнатуры не всегда ясно, чего ожидают от метода. EP>Пример в студию.
Возможно ты прав. Разматывать историю честно говоря сейчас лень, более того, проверить даст ли по рукам компилятор того времени я сейчас всё равно не смогу, и от меня это в любом случае потребует больших временных затрат.
MA>>На фоне всех этих трюков в C++, ручное управление ресурсами в C#, лично для меня не выглядит чем-то более сложным. EP>Все эти "трюки" — два притопа, три прихлопа, и не нужно от забора и до обеда вручную управлять ресурсами.
В C#, в отлиии от C++ — в ручную необходимо управлять только непосредственно ресурсами, и управление ими по большому счету сосредотачивается в библиотечном коде. В C++ полуручник всегда рядом в перемешку с голыми указателями.
EP>Фишка в том что не просто красиво, а ещё и просто, а-ля class Widget{ File x; ... };.
Я вообще абсолютно за вот эту вот C++-сную возможность свободно объявлять свои типы данных и оперировать с ними как с value-типами, а не определять способ их инстанцирования в декларации (как в C#). Более того, в C# структуры не эквиваленты классам (ну, к примеру, для первых нет наследования) — соответственно одно другое не заменяет (хоть это в мире C# и не является проблемой). Но ложка дегтя в C++ больше.
EP>Проблема обычно в том, что действительно есть код где совершенно необоснованное засилье ptr<T>, буквально на ровном месте. Обычно так происходит когда кто-то переходит с управляемых языков, и начинает везде лепить привычные new, потом задалбывается управлять вручную, ещё и огребает проблем с exception safety прям как ТС, и узнаёт про спасительные смарт поинтеры — с этого момента всё и оборачивается в ptr<T>.
Это не тот случай. В своей жизни, кроме нескольких собственных проектв, — я не сталкивался с кодом C++ с экзепшнами — но, это просто случайность.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Проблема, в том, что одни люди не понимают как работать с исключениями, а вторые — не совсем еще осознали, что GC лишь помогает, а детерминированное управление ресурсами там же где и раньше — на ваших плечах.
Ну и где оно, это детерминированное управление ресурсами? В С++ есть деструкторы с гарантией вызова. А в жабошарпах? Ну юзинг есть, но он не универсален. Что, ручками, как в старые добрые времена?
Здравствуйте, T4r4sB, Вы писали:
MA>> Проблема, в том, что одни люди не понимают как работать с исключениями, а вторые — не совсем еще осознали, что GC лишь помогает, а детерминированное управление ресурсами там же где и раньше — на ваших плечах.
TB>Ну и где оно, это детерминированное управление ресурсами? В С++ есть деструкторы с гарантией вызова. А в жабошарпах? Ну юзинг есть, но он не универсален. Что, ручками, как в старые добрые времена?
Здравствуйте, T4r4sB, Вы писали:
F>>А автор что написал? См. выделеное. TB>То есть от крестов — шаг назад?
В прямом трактовании — да. RAII не завезли, как и во все подобные управляемые языки (JS например). Только, это именно о языке.
На потребительские качества это фактически не влияет, и на мой взгляд — наоборот упрощает его использование, потому что никаких лишних сущностей не появляется в принципе. Т.е. прикладные задачи — решаются эффективно, а это основной показатель.
Более того, большинство открытых C++ проектов — содержат столько всякой человеческой ахинеи,что диву даешься.
Слабое звено сейчас, далеко на языковые средства, а человек.
Здравствуйте, fmiracle, Вы писали:
F>А автор что написал? См. выделеное.
Приятно видеть, что кто-то мою ахинею читает. Я фразу 3 раза переписал, что б была понятна. Надо было четвертый.
