Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>будет генерировать исключения или нет. Конечно, можно перестраховаться и все неизвестные функции в try/catch обрамлять (особенно в деструкторах). Но ведь это overhead не слабый получается.
VD>А зачем обрамлять то? Пропускай их и все. Если появится код которому по его логие потребуется обработать исключение, то он и будет знать что и как обрабатывать. А обрабатывать на всякий пожарный — это маразм.
Если в деструкторах, то не маразм, а жизненая необходимость. Деструкторы не должны генерировать или выпускать исключений.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2,
> E> будет генерировать исключения или нет. Конечно, можно перестраховаться и все неизвестные функции в try/catch обрамлять (особенно в деструкторах). Но ведь это overhead не слабый получается.
> А зачем обрамлять то? Пропускай их и все. Если появится код которому по его логие потребуется обработать исключение, то он и будет знать что и как обрабатывать. А обрабатывать на всякий пожарный — это маразм.
Из деструкторов, равно как и из всяких Finalize и Dispose, исключения выпускать не рекомендуется.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[7]: Движутся ли mainstream языки в сторону лиспа?
Здравствуйте, VladD2, Вы писали:
VD>Ну, или кривость дизайна проекта.
Я бы по остерегся бы так лихо отзываться об апачевских проектах.
VD>Народ чтобы не иметь проблем просто перехватывает все подряд.
Плз, куски из анта в студию где что криво и где им просто так перехватить захотелось
VD>По мне так в десктоп приложениях стандартным паттерном обработки исключения является перехват исключений где-то не подолеку от цикла обработки сообщений ОС.
T.е. выходит написание расширяемых приложений к котороым можно добавить фичу не препреписывая низкоуровневый код вблизи от цикла обработки сообшений ОС на традиционных языках сродни танцами с бубном и постоянным оверхедом с обработкой исключений?
Кстати мне лично ничем checked exceptins не мешает Более того не понимаю почему методы наподобие Integer.parseInt(String) выкидывают unchecked exceptions. Единствнное что немнооожко напрягает, это что в catch недоступны локальные переменные объявленные внутри try, стиль — объявляй когда надо, нарушается.
-- Главное про деструктор копирования не забыть --
Re[10]: Движутся ли mainstream языки в сторону лиспа?
pvgoran,
> IM(very)HO checked exceptions лучше рассматривать как альтернативный механизм возврата значений из функции — и использовать соответствующим образом.
В таком случае вопрос: причем к возврату значений из функции механизм обработки исключительных ситуаций? Основная особенность исключений направлена на решение следующей проблемы: код, непосредственно вызывающий потенциально бросающую функцию обычно не в состоянии обработать исключительную ситуацию, и, соответственно, незачем его "заморачивать" обработкой всевозможных кодов возврата и т.п. Исключение можно обработать где-то наверху. Диагностируется оно (обычно) где-то глубоко внизу. Соответственно, механизм обработки исключений "заточен" именно на такой сценарий. throw — внизу, try catch — вверху, ничего в таком духе — между. Если на всех уровнях вводить знание о пролетающих исключениях, то, имхо, теряются все выгоды от механизма обработки исключений, кроме одной: исключение, в отличие от кодов возврата необходимо обработать. Но даже эта выгода серьезно подрывается дизайном checked exceptions в Java: количество try catch, которое люди "лепят", чтоб "обернуть" и т.п.
исключения на промежуточных уровнях, приводит к периодическому "проглатыванию" исключений.
Применительно же к уже существующим реализациям, не содержащим ничего, аналогичного checked exceptions (C++, .Net и т.п.), их введение post factum, вообще, кажется нереальным: имхо, польза от (гипотетически более удачного дизайна, чем в Java) checked exceptions будет только в случае, если это последовательно исполняется на всех уровнях, чего уже нет. Ревизия огромного количества существующего кода для добавления отсутствующих exception specifications, имхо, неосуществима.
Кроме того, в случае generics/шаблонов, вообще затруднительно представить, как именно должен выглядеть обобщенный код, чтоб не накладывать черезмерных ограничений на типы, которыми он может параметризовываться...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>В Яве/C# исключение может вылететь в любой момент (какой-нибудь C>OutOfMemory), а в С++ можно гарантировать, что функции не кинут исключения.
На самом деле OutOfMemoryException вылетают не в C# или еще где, а в CLR или ОС. Точно так же они вылетают в ОС от того же МС. Только вылетают они в виде SEH и по-умолчанию не ловятся С++-ными catch-ами. Это в свою очередь приводит к полному падению приложения.
Ну, да при OutOfMemoryException уже мало что можно поделать. Памяти то нет и обрабатывать исключение просто не чем. А вот NullReferenceException очень даже обрабатывается. При этом в большинстве случае C#-ные приложения продолжают работать дальше, а большинство С++-ных выпадает "в осадок".
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>mishaa wrote:
>> Тем не менее C#-цы вроде не жалуются, а просто почти не используют >> try-catch, и утверждают что так и надо. интересно вобше с Exceptinos >> получается вроде и без них никак, но в тоже время и не переборшить >> надо. Есть интересно какие-нибудь Exception usage patterns ну или >> Style guidelines?
C>Жалуются, кстати, — те кто перешел на С# из Java. Где-то находил пост от C>Cameron Purdy на TheServerSide.com, что их до того это напрягло, что они C>стали использовать third-party тулзу для отслеживания обработки C>исключений в C#.
Это из серии "мотоцикл продал, но привычка осталась". Жалуются те кто не умет использовать технологию так как задумано е создателями. Вот на Яву действительно жалуются. Причем те кто еею пользуются. Очеть многие популярные Явские фрэймворки обходят Checked exceptions тем или иным образом.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А вообще, недавно перечитал об исключениях у Страуструпа и Саттера и пришел к мнению, что лучше три раза подумать, прежде чем throw написать.
Это потому как С++. Я в когда пишу на Шарпе throw пишу там где вижу, что некоторая ситуация не являетс штатной для данного кода. Ну, там параметр кривой — throw. Обязательный файл не найден — throw...
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Вот собственно об этом я и говорил. Спецификация исключений, имхо, в теории полезная штука. Но вот в C++ и Java она реализована, имхо, неудачно.
Согласен с одной оговоркой. Описание исключений генерируемых методом должен делать компилятор. Причем без единой подскзки. Вся информация у него есть. А я как потребитель должен иметь возможность легко узнать список исключений которые может выдать тот или иной метод.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Если в деструкторах, то не маразм, а жизненая необходимость. Деструкторы не должны генерировать или выпускать исключений.
Деструкторы — это зло! И чем их меньше, тем лучше.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Из деструкторов, равно как и из всяких Finalize и Dispose, исключения выпускать не рекомендуется.
Ну, из Dispose это неприятно но не смертельно. Да и суть Dispose-ов все же неуправляемые ресурсы освобождать. По сему писать их часто не приходится и проблем особых не возникает. А с деструкторами согласен.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Движутся ли mainstream языки в сторону лиспа?
Здравствуйте, mishaa, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>Ну, или кривость дизайна проекта. M>Я бы по остерегся бы так лихо отзываться об апачевских проектах.
Я вообще-то не об апаческий, а вообще. Но почему, интересно, отзываться об Апачевских проектах дурно — это табу? Открытые проекты с разным контингентов участников...
Ну, да соглашусь, что в случае Явы куча try-ев это скорее необходимость вызванная идеологией языка. Что в прочем не делает их наличие полезным.
VD>>Народ чтобы не иметь проблем просто перехватывает все подряд. M>Плз, куски из анта в студию где что криво и где им просто так перехватить захотелось
Да, статистики более чем достаточно. Ну, и не нужно забывать про выделнное жирным. (цитату ты поквотил не очень красиво ).
M>T.е. выходит написание расширяемых приложений к котороым можно добавить фичу не препреписывая низкоуровневый код вблизи от цикла обработки сообшений ОС на традиционных языках сродни танцами с бубном и постоянным оверхедом с обработкой исключений?
А расширяемости 1000 try/catche-ев никак не помогает. Можно строить прекрасные компонентные системы которые и без оных будут расширяться. Просто относиться к исключениям нужно как к исключениям, а не как к части программы.
M>Кстати мне лично ничем checked exceptins не мешает
Рад за тебя. Другим мешают. К тому же ненужная вешь не становится нужной от того, что она не мешает.
M> Более того не понимаю почему методы наподобие Integer.parseInt(String) выкидывают unchecked exceptions.
О, как?! А если бы она выкидывала checked, то жить стало бы лучше и приятнее? Вот в дотнете тоже содрали явский Integer.parseInt. И все плевались до тех пор пока во втором фрэйморке не ввели TryParse который просто возвращает булево значение вместо того чтобы кидать исключение. В итоге проблема исчезла. И никакие checked exceptions не понадобились. А все потому, что при проектировании в Parse была изначально заложена ошибка (вренее скопирована с Явы). Ошибка банальная... Неверные данные в Parse/parseInt очень часто бывают не исключительно, а совершенно шаттной ситуацией. Это значит, что изначально нужно было делать две версии Parse/parseInt или вводить в эти функции параметр который бы регулировал генерацию исключения.
Я в таких случаях обычно действительно пользуюсь try/catche-ем, но один раз, в обертке закрывающей этот прощет архитекторов фрэймворка.
M> Единствнное что немнооожко напрягает, это что в catch недоступны локальные переменные объявленные внутри try, стиль — объявляй когда надо, нарушается.
Объявляй их во вне try. В чем тут проблема? Код то твоей.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> На самом деле OutOfMemoryException вылетают не в C# или еще где, а в CLR или ОС. Точно так же они вылетают в ОС от того же МС. Только вылетают они в виде SEH и по-умолчанию не ловятся С++-ными catch-ами. Это в свою очередь приводит к полному падению приложения.
-1. При недостаче памяти в C++ вылетает std::bad_alloc.
> Ну, да при OutOfMemoryException уже мало что можно поделать. Памяти то нет и обрабатывать исключение просто не чем.
-1. После раскрутки стека и, соответственно, освобождения некоторой памяти вполне может образоваться нужный запас.
> А вот NullReferenceException очень даже обрабатывается. При этом в большинстве случае C#-ные приложения продолжают работать дальше, а большинство С++-ных выпадает "в осадок".
NullReferenceException — типичная логическая ошибка. Внешнему коду доверять странно, если он передал нулевую ссылку там, где этого делать нельзя. Соответственно, надеяться на то, что внешний код корректно "восстановится", тоже не приходится: он уже находится в каком-то невалидном состоянии, на которое не рассчитывали при его разработке. Попытка "восстановления" после подобной ошибки зачастую приводит к попаданию в нормальный поток исполнения с нарушенными инвариантами, после чего приложение скорее не работает, чем работает. Т.е., в случае управляемых сред, оно при этом обычно не "падает", но это даже хуже, т.к. у пользователя создается иллюзия исправной работы, в то время, как "внутри" уже самый настоящий глюкодром. Это очень легко наблюдать на многих приложениях, написанных на Java и C# в случаях возникновения непредусмотренных исключительных ситуаций. Т.к. чтоб работать в случае нарушенных инвариантов, нужно проверять все на свете, что, очевидно, сделать невозможно.
Вообще же, в более строгих случаях, для приложений с критическими требованиями, попытки продолжения работы после диагностирования логической ошибки традиционно недопустимы: в таком состоянии приложение должно максимально коротким путем завершить свою работу, при необходимости сохранив текущие данные. Далее, в случае серверного приложения -- задача watch dog сохранить crash dump, log файл и т.п., и перезапустить приложение.
В обсуждении, на которое ссылка уже давалась, этот момент подробно рассматривается.
В частности, приводится вполне наглядный пример диагностики в системе автоматического пилотирования отрицательной высоты. Что бы ты в этом случае предпочел, пребывая в самолете: чтоб система пыталась "восстановиться", и продолжить управление, как ни в чем не бывало, или же чтоб она все-таки завершила автопилотирование в надежде на независимые резервные системы с последующим переходом на ручное управление, буде те также откажут?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> E>Вот собственно об этом я и говорил. Спецификация исключений, имхо, в теории полезная штука. Но вот в C++ и Java она реализована, имхо, неудачно.
> Согласен с одной оговоркой. Описание исключений генерируемых методом должен делать компилятор. Причем без единой подскзки. Вся информация у него есть.
Гм, не вполне понял мысль... Давай конкрентнее, для того же C#:
interface I
{
void f();
};
Сборка 1:
class C1 : I
{
void f() // или что надо написать, чтоб реализовать I::f...
{
throw new Exception1();
}
};
Сборка 2:
class C2 : I
{
void f() // или что надо написать, чтоб реализовать I::f...
{
throw new Exception2();
}
};
. . .
Сборка N:
void g( I i )
{
i.f(); // И какой список здесь должен генерировать компилятор?..
// Какие сборки будут подгружены, кроме данной, и от какого класса придет I — :xz:
}
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>Жалуются, кстати, — те кто перешел на С# из Java. Где-то находил пост от C>Cameron Purdy на TheServerSide.com, что их до того это напрягло, что они C>стали использовать third-party тулзу для отслеживания обработки C>исключений в C#.
И что они делали со знанием того где и какое исключение кидается?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Павел Кузнецов wrote:
> C> Однако справедливые возражения того же Гослинга или Гриффита > C> (http://octopull.demon.co.uk/java/ExceptionalJava.html) почему-то не > C> находятся сразу же. > Гм... Эту ссылку я приводил, там не возражения, а как раз рекомендация > не налегать > на checked exceptions...
A programming language can't solve all the problems. A language can't
guarantee that no matter how screwed up the environment gets the program
will survive. But anything the language can do to increase the
probability that programs will be reasonably graceful under fire is a
good thing. For example, just making people at least willfully ignore
return codes helps. In Java you can ignore exceptions, but you have to
willfully do it. You can't accidentally say, "I don't care." You have to
explicitly say, "I don't care."
Тут я согласен, исключение — это такой "код возврата" для аварийных
ситуаций, который игнорировать не рекомендуется. А если игнорировать
хочется — то надо делать это явно.
Минус такого подхода — некоторый overhead в лишних try{..}catch(...){}
блоках. Вот чтобы его убрать и нужно придумать какие-нибудь механизмы.
> C> Причем несложно заметить, что основные возражения о exception'ах > идут от > C> любителей динамических языков, с их идеологией "нафиг нам системы > C> безопасности не нужны — у нас есть юнит-тесты". > Это Bruce Eckel. Остальные приводят достаточно внятную аргументацию, > основным положением > которой является то, что checked exceptions мешают основной идее > исключений: изоляции > промежуточных уровней от знания об исключительных ситуациях, > возникающих на нижних.
А насколько нужна изоляция? Какой-нибудь null-pointer-exception через
несколько уровней потеряет всякий смысл, в нем не будет полезной
информации для попытки восстановить выполнение.
Павел Кузнецов wrote:
> ??>> Насколько я знаю, компиляторы не ругаются, если в функциях со > ??>> спецификатором throw() вызываются функции со спецификацией исключений > ??>> или вообще без спецификации исключений (и поэтому, потенциально, > ??>> могущие порождать исключения). > C> Вообще-то, по пункту 15.4.4 компилятор должен ругаться на такое. > Гм... 15.4/4 говорит о присваивании указателей на функции, имеющих > exception specification...
По памяти пункт сказал — и как всегда неправильно. Там в предидущем
пункте говорится о спецификации исключениях в наследниках, но про
контроль за throw() действительно ничего нет. Так что это я глючу
VladD2 wrote:
> E>Вот собственно об этом я и говорил. Спецификация исключений, имхо, в > теории полезная штука. Но вот в C++ и Java она реализована, имхо, > неудачно. > Согласен с одной оговоркой. Описание исключений генерируемых методом > должен делать компилятор. Причем без единой подскзки. Вся информация у > него есть. А я как потребитель должен иметь возможность легко узнать > список исключений которые может выдать тот или иной метод.
Welcome to IDEA. Не компилятор, правда, но вполне сойдет.
Павел Кузнецов wrote:
> Сборка 1: > >class C1 : I >{ > void f() // или что надо написать, чтоб реализовать I::f... > { > throw new Exception1(); > } >}; > >
В случае с checked exceptions — ошибка компиляции.
> Сборка N: > >void g( I i ) >{ > i.f(); // И какой список здесь должен генерировать компилятор?.. > // Какие сборки будут подгружены, кроме данной, и от какого класса придет I — >} >
Если checked exceptions есть, то в обоих сборках не должно быть
задекларировано бросков исключений.
IT wrote:
> C>Жалуются, кстати, — те кто перешел на С# из Java. Где-то находил > пост от > C>Cameron Purdy на TheServerSide.com, что их до того это напрягло, что > они > C>стали использовать third-party тулзу для отслеживания обработки > C>исключений в C#. > И что они делали со знанием того где и какое исключение кидается?
Смотрели, чтобы оно было обработано. Просто эти товарищи пишут 24x7
систему, которая должна работать как можно безглючнее.
У них это, кстати, получилось. За мой опыт работы с Tangasol
Coherence'ом мне его свалить не удалось ни разу.
Более того не понимаю почему методы наподобие Integer.parseInt(String) выкидывают unchecked exceptions. Единствнное что немнооожко напрягает, это что в catch недоступны локальные переменные объявленные внутри try, стиль — объявляй когда надо, нарушается.
Ну, и не нужно забывать про выделнное жирным. (цитату ты поквотил не очень красиво 
).
Если нам не помогут, то мы тоже никого не пощадим.
