Когда Java быстрее C++ - сравнение производительности

> Кстати, я так и не понял, что вам в них не понравилось. Хотя конечно в языках типа C# и Java они смотрятся "более к месту", но там уже нужен трехступенчатый try-catch-finally (зато все высвобождение ресурсов явно и очевидно).

Все) До сих пор вспоминается пример с функцией из трех строк, которая имеет 17 ветвей исполнения. Я был в шоке, честно говоря, и одного этого аргумента мне хватило.

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

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

> А если серьезно (хотя куда уж серьезней) механизм исключений нарушает принцип "черного ящика". Т.е. чтобы корректно работать с функцией, мне надо знать ее детали реализации (генерируемые исключения).

Генерируемые функцией исключения - это не часть реализации, а часть ее интерфейса (не зря в яве есть ключевое слово throws). Вы ведь параметры функции и тип возвращаемого значения не считаете деталями ее реализации?

> Генерируемые функцией исключения - это не часть реализации, а часть ее интерфейса (не зря в яве есть ключевое слово throws). Вы ведь параметры функции и тип возвращаемого значения не считаете деталями ее реализации?

Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.

> Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.

А вот это уже ошибка в дизайне языка. Исправленная в той же яве.

>> Если я ошибусь с параметром или типом значения - компилятор меня остановит. Подлые исключения будут ждать своего часа.
> А вот это уже ошибка в дизайне языка. Исправленная в той же яве.

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

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

Вы упорно сводите все на исключения как таковые. Я еще раз спрошу: к самой концепции исключений (и, например, ее реализации в яве) какие у вас претензии?

>Вы упорно сводите все на исключения как таковые. Я еще раз спрошу: к самой концепции исключений (и, например, ее реализации в яве) какие у вас претензии?

Я не работал с Java, поэтому об исключениях сужу только по опыту программирования в С++. Такое же отношение у меня сложилось и к концепции в целом.

Тогда, наверное, не стоит делать поспешных выводов?

Вот скажите, если бы компилятор заставлял вас перечислять все исключения, которые вы кидаете в функции, при ее объявлении, а так же использовал эту информацию в дальнейшем для проверки наличия соответствующих try/catch блоков при вызове этой функции (а их отсутствие считается ошибкой!) - так уже лучше?

>Вот скажите, если бы компилятор заставлял вас перечислять все исключения, которые вы кидаете в функции, при ее объявлении, а так же использовал эту информацию в дальнейшем для проверки наличия соответствующих try/catch блоков при вызове этой функции (а их отсутствие считается ошибкой!) - так уже лучше?

Спецификация исключений?

А что вы думаете по поводу следующего:
http://gotw.ca/publications/mill22.htm
?

Это именно про грабли в C++. Там это действительно сделано по принципу "не пришей кобыле хвост", т.к. во-первых толком не используется (предполагалось что это поможет оптимизировать код, но на самом деле все оказалось не так просто), а во-вторых вызывает кучу нестыковок с прочими фичами C++ (typedef, указатели на функции etc) в силу непродуманного дизайна этой фичи - видимо, уж больно торопились включить... Надо ли говорить, что в яве все совсем не так... там нарушение exception specification (самой функцией или же тем, кто ее вызывает) - ошибка этапа _компиляции_.

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

QString const& error(ErrorEnum number, int* indeffinedError);

QString const& error(ErrorEnum number) throw(indeffinedErrorException);

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

> Подлые исключения будут ждать своего часа.
Они не подлые... они честные. Забил на ошибку - получил aborted. В отличии от кодов возврата, где забил на ошибку - получил хрен знает что...

>Надо ли говорить, что в яве все совсем не так... там нарушение
>exception specification (самой функцией или же тем, кто ее вызывает) -
>ошибка этапа _компиляции_.
Вот объясните мне... зачем от такой полезной практики отказались в C#?

> так как я не вижу выигрыша

Выигрыш в том, что 1) имеем стандартизированный способ сигнала об ошибке, и 2) ексепшены можно (и нужно) ловить не сразу после вызова функции, а там, где это имеет смысл. То есть проще говоря вместо того чтоб в каждой функции после вызова malloc проверять, а не NULL ли нам вернули (то бишь память кончилось), словить OutOfMemoryException где-нибудб в начале цепочки вызовов, и деликатно сообщить пользователю о неприятности. Такое разумеется можно сделать и с кодами ошибок, но тогда chaining придется делать ручками.

> Вот объясните мне... зачем от такой полезной практики отказались в C#?

Потому что ex-VB-программеров достает писать throws и try-catch. Им предпочтительней чтоб оно работало по принципу "вылетит - ну и х с ним!", делая вид, что всякие там OutOfMemoryException и StreamException в их программе не могут случиться по определению ;)

(знаю, т.к. сам такой был...)