Похоливарим еще? (java, checked exceptions)

← →
Сусл © (2007-11-20 17:58) [160]

> [159] Mystic © (20.11.07 17:48)

А вот возражу я. И вот чем.

1. Для начала опишу ситуацию. У меня есть некий фреймворк. Писан на Дельфи. Активно его использую. В настоящий момент я еще не сделал то, о чем сейчас скажу, но обязательнос сделаю.
У меня будут обязательными все три звездочки из твоего поста! Плюс еще много других будет ограничений и деклараций. Не вижу ничего в этом плохого, т.к. фреймворк узко специализирован, причем он скорее не ООП парадигмы, а АОП придерживается. Т.е. специфичный, удобный с своей области язык (фреймворк).

2. Вот давай теперь посмотрим на java. Конечно, java не сколько узко заточена под задачу как мой фреймворк. Безусловно JAVA имеет более широкую область применения. Но в тоже время область применения JAVA в текущее время в большнстве своем (имхо, конечно) можно описать как server-side внутри фреймворков (коих до фига, насколько я знаю). Все же JAVA уже, чем общий язык. Ну не придет же в голову писать аркаду на java?

3. Delphi еще более широкий по области применения язык. Может я, конечно, и ошибаюсь и область дельфи это исключительно потрепаца на delphimaster, но что-то мне говорит о том, что

select count(*) from delphiusage group by(area)

выдаст большее число, чем аналогичный запрос для JAVA.

РЕЗЮМЕ
А резюме простое. JAVA занимает промежуточное положение между языками общего назначения и узкоспециализированными фреймворками. Посему JAVA не свойственнена такая зажатость, как у узкоспециализированных фреймворков, но в тоже время на нее наложены более строгие ограничения, чем на язык общего назначения.

ЗЫ Про j2me не говорю, имхо отдельная тема.

← →
Petr V. Abramov © (2007-11-20 18:20) [161]

> Сусл © (20.11.07 17:58) [160]
а какой положительный РЕЗУЛЬТАТ мы в сухом остатке имеем благодаря этим ограничениям? Где-то в метеданых появляются сведения обо всех exception, которые метод может поднять? Вообще-то это можно было и на компилятор возложить, а не заставлять руками писать.

← →
iZEN © (2007-11-20 20:45) [162]

> Petr V. Abramov © (20.11.07 17:35) [158]
>
> > Сусл © (20.11.07 17:19) [157]
> > которое приводит к повышению контроля за кодом есть гуд,
>
> в богоугодном деле - главное лоб не расшибить.
> если качества становится больше на 10%, а гимра - на 100,
> ну его нафик такое средство

поэтому и выбирают .Net — там думать меньше надо, как в Delphi. :))

← →
Petr V. Abramov © (2007-11-20 23:09) [163]

> iZEN © (20.11.07 20:45) [162]
ну да java - это ж opensource, там главное побольше думать и руками по клаве стучать, чем больше, чем лучше.

← →
Petr V. Abramov © (2007-11-20 23:16) [164]

> iZEN © (20.11.07 20:45) [162]
РЕЗУЛЬТАТ-то какой от этого КОНТРОЛЯ? Можно без документации прочитать, какие исключения поднимет метод . ЕЩЕ? Если все, сопровождающего гимра не стОит. И этот скромный результат можно достичь другими путями без гимра вовсе.

комментарии писать надо? надо.
давайте сделаем так, чтобы без комментариев программа не компилилась :)
комментарии от этого появятся? появятся. Чужой код читать, глаза не вывихнув, можно будет? Можно, но не чаще, чем без фичи.

← →
Petr V. Abramov © (2007-11-20 23:29) [165]

допускаю, что при разработке драйвера тормозов ядерной ракеты
> если качества становится больше на 10%, а гимра - на 100,
такое средство оправдано.
Но в случае checked exceptions и этим не пахнет. ИМХО.
P.S. я ж разобраться в вопросе хочу :)

← →
iZEN © (2007-11-21 08:51) [166]

> Petr V. Abramov © (20.11.07 23:16) [164]
>
> > iZEN © (20.11.07 20:45) [162]
> РЕЗУЛЬТАТ-то какой от этого КОНТРОЛЯ? Можно без документации
> прочитать, какие исключения поднимет метод . ЕЩЕ? Если все,
> сопровождающего гимра не стОит. И этот скромный результат
> можно достичь другими путями без гимра вовсе.

КАКИМИ путями? Если, например, исходники библиотеки потеряны. Сами class-файлы обфусцированы.

Другой пример — "AV" в Delphi аналогична java.lang.Error — в обоих случаях восстановление НЕВОЗМОЖНО. Но в Delphi при этом программа завершается аварийно с возможным сносом половины системы, причём AV можно поймать буквально на ровном месте (я, например, знаю, как подвесить WinXP из-под профиля обычного непривилегированного пользователя); в Java есть большая вероятность при Error программу завершить корректно, закрыв ресурсы, и сноса системы не будет вообще.

Java обеспечивает хоть какую-то возможность восстановления после сбоя. Delphi — практически нет.

← →
Petr V. Abramov © (2007-11-21 09:46) [167]

> iZEN © (21.11.07 08:51) [166]
> Если, например, исходники библиотеки потеряны. Сами class-файлы обфусцированы.
сама библиотека потеряна, голову дома забыл :)

> КАКИМИ путями?
генерацию этих метаданных вполне можно возложить на компилятор.

> Java обеспечивает хоть какую-то возможность восстановления после сбоя. Delphi — практически нет.
как-то голословно. Дельфийская программа прекрасно работает и после AV, и после StackOverflow. Т.е. не прекрасно, а как написана, так и работает. :)Но не гибнет.

← →
Romkin © (2007-11-21 10:53) [168]

> Java обеспечивает хоть какую-то возможность восстановления
> после сбоя. Delphi — практически нет.

Ты эда. То, что обеспечивает это, называется Виртуальная Машина.

← →
Mystic © (2007-11-21 12:01) [169]

> допускаю, что при разработке драйвера тормозов ядерной ракеты

Там требуется доказательство правильности :)

> Но в Delphi при этом программа завершается аварийно с возможным
> сносом половины системы

Во-первых, это уже проблема операционной системы, не языка программирования. Во-вторых, только так и можно реализовывать решение системных задач :) Так что для кого-то это фича ;) В-третьих, наличие AV говорит просто об ошибку в программе. Зачастую по адресу 0x00000000. Ну замени его на Null reference exception, что поменяется?

Да, есть вероятность того, что будет запить по поврежденному указателю и что-то в памяти перезапишется. Я работал напрямую с указателями очень часто, но такая ситуация возникала почему-то очень редко. Собственно это есть плата за дополнительные возможности (начал использовать указатели, ассемблерные вставки, значит ССЗБ), и я не скажу, что это очень кошмарно.

← →
pasha_golub © (2007-11-21 13:44) [170]

> iZEN © (21.11.07 08:51) [166]

> Но в Delphi при этом программа завершается аварийно с возможным
> сносом половины системы

Это ж надо. А пацаны и не знают. Да мне бы за такое ноги повырывали, ан нет, логи шлют, и после фикса еще и спасибо говорят.

← →
Сусл © (2007-11-21 14:13) [171]

> [164] Petr V. Abramov © (20.11.07 23:16)
> комментарии писать надо? надо.
> давайте сделаем так, чтобы без комментариев программа не
> компилилась :)
> комментарии от этого появятся? появятся. Чужой код читать,
> глаза не вывихнув, можно будет? Можно, но не чаще, чем без
> фичи.

ты не поверишь, что в некоторых конторах репозитарий не принимает исходники, которые не прошли морфологический анализ на наличие комментариев. как ты думаешь, почему там не делают комментарии типа, чтобы обламнуть анализатор

// бла-бла-бла это коммент о функции MyFunc. // как я круто обдурил анализатор. // всем привет!

:)

← →
pasha_golub © (2007-11-21 14:54) [172]

> Сусл © (21.11.07 14:13) [171]
>
>

> ты не поверишь, что в некоторых конторах репозитарий не
> принимает исходники

Это глупо, как по мне. Достаточно, чтобы юзер комментировал Commit.

← →
Сусл © (2007-11-21 15:41) [173]

> [172] pasha_golub © (21.11.07 14:54)
> > ты не поверишь, что в некоторых конторах репозитарий не
> > принимает исходники
> Это глупо, как по мне. Достаточно, чтобы юзер комментировал
> Commit.

В жизни часто бывает все глупо, что не по себе.

Каждый публичный метод должен быть описан. И описан хорошо: параметры, побочные эффекты, семантика, исключение и пр.

← →
Mystic © (2007-11-21 16:04) [174]

> Как ты думаешь, почему там не делают комментарии типа, чтобы
> обламнуть анализатор

По той же причине, что и не посылают менеджера на три буквы прямым текстом.

Лично мне комментарии в коде обычно только мешают, ибо
(1) засоряют текст, отвлекая внимание на их изучение;
(2) указывают на очевидные вещи, которые я и так знал;
(3) не дают ответа на интересующий вопрос.
Например, когда есть функция memmove, то самый распространенный стиль комментариев состоит в том, чтобы описать назначение функции (что в общем-то понятно) и параметры функции (что очевидно из их названия). А вот вопрос, поддерживаются ли перекрывающиеся блоки обычно замалчивается.

← →
Сусл © (2007-11-21 16:15) [175]

> [174] Mystic © (21.11.07 16:04)
> Например, когда есть функция memmove, то самый распространенный
> стиль комментариев состоит в том, чтобы описать назначение
> функции (что в общем-то понятно) и параметры функции (что
> очевидно из их названия). А вот вопрос, поддерживаются ли
> перекрывающиеся блоки обычно замалчивается.

ну может ты не те комментарии читаешь?

ну давайте сейчас еще холивар организуем о вреде комментариев, единственной причиной которой является лень их писать.

← →
Mystic © (2007-11-21 16:38) [176]

> ну может ты не те комментарии читаешь?

Какие написаны, такие и читаю (правда не часто). Какие не написаны, тех не читаю.

> ну давайте сейчас еще холивар организуем о вреде комментариев,
> единственной причиной которой является лень их писать.

Были уже, и на этом форуме и не на этих... :) Единого мнения в этом вопросе нет :)

← →
iZEN © (2007-11-21 17:51) [177]

> Petr V. Abramov © (21.11.07 09:46) [167]
>
> > iZEN © (21.11.07 08:51) [166]
> > Если, например, исходники библиотеки потеряны. Сами class-
> файлы обфусцированы.
> сама библиотека потеряна, голову дома забыл :)

ну и

> Petr V. Abramov © (21.11.07 09:46) [167]
> > КАКИМИ путями?
> генерацию этих метаданных вполне можно возложить на компилятор.

Возложите "генерацию метаданных" на компилятор Delphi, чтобы он поддержал статическую линковку вашей программы с левоприобретённой BPL-библиотекой.
Исходники утеряны. Документации нет. Есть только BPL. И што с ней делать?

javac, например, может разрулить использование любой библиотеки, от которой есть только .class-файлы.

> Petr V. Abramov © (21.11.07 09:46) [167]
>
> > Java обеспечивает хоть какую-то возможность восстановления
> после сбоя. Delphi — практически нет.
> как-то голословно. Дельфийская программа прекрасно работает
> и после AV, и после StackOverflow. Т.е. не прекрасно, а
> как написана, так и работает. :)Но не гибнет.

Правильно. Деградирует и гибнет операционная система. Программе на это наплевать. :)

← →
Mystic © (2007-11-21 18:25) [178]

> javac, например, может разрулить использование любой библиотеки,
> от которой есть только .class-файлы.

По сути class-файл это и есть сокращенная форма хранения исходников :)

> Деградирует и гибнет операционная система. Программе на
> это наплевать. :)

Начнем с того, что погубить операционную систему непросто. Надо знать, куда и с какой силой ударить. Случайно это у меня это выходило только с Windows 98 (один раз). С другой стороны, баг в реализации виртуальной машины может привести к аналогичным последствиям ;)

← →
Юрий Зотов © (2007-11-21 19:01) [179]

Однако же, не все так просто...

Реальный случай. Возникла у меня на днях необходимость сделать объект клонируемым. Согласно доке, для этого нужно:

1. В заголовке класса объявить: implements Cloneable
2. Перекрыть protected метод clone базового класса Object и сделать его public.
3. В перекрытом методе clone реализовать создание клона, сначала вызвав в нем унаследованный метод, который создает копию "бит в бит".

В базовом классе Object метод clone имеет такое объявление:
protected Object clone() throws CloneNotSupportedException
причем унаследованный метод clone возбуждает CloneNotSupportedException в том случае если в объявлении класса не объявлена реализация им интерфейса Cloneable.

Все ясно и никаких проблем нет. Но есть несколько вопросов.

Вопрос первый.
Если я перекрываю метод clone и делаю его public, то делаю это, видимо, не просто так, а именно для того, чтобы сделать объект клонируемым. Тогда зачем нужно еще и объявлять то же самое в заголовке?

Вопрос второй.
И наоборот - раз уж в заголовке моего класса объявлено, что интерфейс Cloneable им поддерживается, то унаследованный метод clone исключения CloneNotSupportedException выбросить не может. Мой перекрытый метод clone его тоже не выбрасывает. В таком случае почему мне навязывают объявление этого метода с якобы выбрасываемым исключением, если это самое исключение выбросится не может физически?

Но это все семечки - а вот самое главное.

Вопрос третий.
Перекрытый мною метод clone обращается к БД - то есть, может возникнуть исключение SQLException. Но выбросить его я не могу, потому что в заголовке метода декларировано только CloneNotSupportedException. Что ж, думаю, нет проблем - щас мы завернем одно в другое. И пишу:
try { ... } catch (SQLException e) { throw new CloneNotSupportedException("Мое сообщение", e); }

Казалось бы, все хорошо? А фигушки! Оказывается, у класса CloneNotSupportedException есть один конструктор с параметром String и второй конструктор вообще без параметров. А на вызов конструктора с параметрами (String, Throwable) идет ругань - хотя такой конструктор есть у класса - прародителя всех исключений Throwable и этот конструктор public.

Что ж, думаю, ладно, мы его сначала просто создадим, потом сделаем ему setCause(e), а уж потом возбудим. И все будет ОК.

А фиг-то! Нет такого метода - setCause.

Что ж это получается - что завернуть в исключение CloneNotSupportedException другое исключение, выходит, нельзя?

Но тогда сабж ветки снова обретает актуальность.

← →
Сусл © (2007-11-21 19:06) [180]

Юра, ты папааал... :)

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

у меня вопрос: почему ты не хочешь сделать Runtime исключение?

← →
C0s (2007-11-21 19:59) [181]

на 179:
1) и 2) - никто не заставляет у конкретной реализации метода переписывать весь список throws метода предка. у конкретных (в отличие от abstract и интерфейсных) методов всегда пишутся только те исключения, которые он реально может выбросить

3) если метод clone лазит в БД, то не нужно вообще это делать через clone, сделай лучше копирующий конструктор с теми исключениями, которые тебе нравятся.

ps. за 5+ лет полёта на java мне ни разу вообще не довелось додуматься до использования метода clone

← →
Сусл © (2007-11-21 20:47) [182]

кстати да, сейчас только проверил, что можно сужать список исключений при перекрытии. а вот расширять нельзя, но это и правильно имхо (где-то писал я выше).

← →
jack128_ (2007-11-21 20:59) [183]

> А на вызов конструктора с параметрами (String, Throwable)
> идет ругань - хотя такой конструктор есть у класса - прародителя
> всех исключений Throwable и этот конструктор public.

не понял, как это? у предка есть public метод, а у потомка нет??? Я думал, что такой бред тока в С++ есть.

← →
Сусл © (2007-11-21 21:00) [184]

> [183] jack128_ (21.11.07 20:59)

по умаолчанию у классов контуркторы не public.
т.е. если ты хочешь сделать констурктор public , ты должен упомянуть его в потомке и сказать, что он public.

← →
jack128_ (2007-11-21 21:01) [185]

> хотя такой конструктор есть у класса - прародителя всех
> исключений Throwable и этот конструктор public.

Ы?

← →
Petr V. Abramov © (2007-11-21 21:05) [186]

> Сусл © (21.11.07 14:13) [171]
> почему там не делают комментарии типа, чтобы обламнуть анализатор
думаю, потому что там так принято. И БЕЗ УЩЕРБА наработанному можно перейти на политику "давать нормальные имена переменным". В той же VCL комментариев откровенно мало, но они почти все по делу, а не
commit; // в базу!

> iZEN © (21.11.07 17:51) [177]
> Возложите "генерацию метаданных" на компилятор Delphi, чтобы он
> поддержал статическую линковку вашей программы с левоприобретённой BPL-библиотекой.
статическая линковка и BPL - вещи из разных опер.

> Сусл © (21.11.07 15:41) [173]
> Каждый публичный метод должен быть описан.
описано ЧТО он делает или КАК он делает?
если КАК - значит, надо выкинуть нафик идею виртуальных методов и предложить что-то свое. Или сказать, что виртуальные методы - хорошо, но от них столько гимра, что использовать их не надо. И обосновать.

← →
Сусл © (2007-11-21 21:12) [187]

> [185] jack128_ (21.11.07 21:01)
> > хотя такой конструктор есть у класса - прародителя всех
> > исключений Throwable и этот конструктор public.
> Ы?

Что Ы? Справку по языку просто Юре надо читать :)
Ну взять Эккеля, например. И всего его прочесть за 3-4 недели.
Тогда и проблем будет меньше.

Если по сути твоего Ы, то конструкторы нужно явно объявлять.

← →
Сусл © (2007-11-21 21:14) [188]

> [186] Petr V. Abramov © (21.11.07 21:05)

Ты видел доку к методам в стандартной библе от java?

Вот например. Чем плохо?

/** * Constructs a new exception with the specified detail message and * cause. <p>Note that the detail message associated with * cause is not automatically incorporated in * this exception"s detail message. * * @param message the detail message (which is saved for later retrieval * by the {@link #getMessage()} method). * @param cause the cause (which is saved for later retrieval by the * {@link #getCause()} method). (A <tt>null</tt> value is * permitted, and indicates that the cause is nonexistent or * unknown.) * @since 1.4 */ public Exception(String message, Throwable cause) { super(message, cause); }

Вообще, поставь себе JDK+NetBeans. Много времени не займет. Зато многие вопросы уйдут.

← →
jack128_ (2007-11-21 21:19) [189]

> Если по сути твоего Ы, то конструкторы нужно явно объявлять.
в _каждом_ классе?? то есть чтобы сделать конструктор public - нуно явно в каждом потомке его объявить? Ну.. Возможно что то в этом есть. Если в джаве нет метаклассов.

> [189] jack128_ (21.11.07 21:19)

Я сам java плохо знаю (вернее почти не знаю). Иногда к товарищу своему обращаюсь за констуальтацией (C0s, кстати - это он), когда хочу что-то понять получше, ну и сам пробую в NetBeans.

Могу по поводу java сказать одно - у нее есть философия. Возможно, что не совсем привычная программисту на Дельфи. Но знать ее, если собираешься писать на java, нужно обязательно. Благо и одноименная книга есть :)

> Сусл © (21.11.07 21:14) [188]
к VCL Help есть, в котором это все написано.
если в java этот хелп - в комментариях в заголовках - тоже сойдет. А почему бы и список exception`ов там не прописать?

> Вообще, поставь себе JDK+NetBeans. Много времени не займет. Зато многие вопросы уйдут.
а у меня их нет :)
если использование виртуальных методов, скажем так, затруднено, нафик эту жабу. про какие-то дополнительные ПОЛЕЗНЫЕ фичи сопоставимой полезности никто, по крайней мере в этой ветке, не сказал

> Могу по поводу java сказать одно - у нее есть философия.
ну отсутствием ЭТОГО никто не страдает :)
А философам, как известно, даже ластики не нужны.

Еще раз - кроме того, что список поднимаемых исключений МОЖНО ПОСМОТРЕТЬ
результат какой-нить есть от фичи?

> а у меня их нет :)

У меня есть - как на этой *не чего нить сделать. Включая весьма интересные комменты самой Sun по поводу кривого инсталера. Работать можно, но вот гемор с IDE......

> tesseract © (21.11.07 21:41) [194]
> У меня есть - как на этой *не чего нить сделать.
судя по всему, ответ универсальный: ректально :)

ИМХО, надо на каком-нить жабогуруссом форуме задать вопрос от имени Delphimaster:
сhecked exceptions с витруальными методами совместимы хорошо или плохо?
ветку (эту) закрыть, открыть новую со ссылкой на жабский форум, читать и между собой комментировать
:)
А то тут большинство в жабе чайники, за exception относительгно очень малого числа читателей/писателей
:)))

> Petr V. Abramov © (21.11.07 22:36) [196]
> ИМХО, надо на каком-нить жабогуруссом форуме задать вопрос
> от имени Delphimaster:сhecked exceptions с витруальными
> методами совместимы хорошо или плохо?

Такой флейм регулярно возникает в разных форумах.
Он просто не интересен уже, ибо имеет одну отличительную черту - противники мало читали книг по java. Не то, чтобы эти книги нужно читать, как мантру. Дело в том, что сложно спорить, если имеешь мало знаний в предмете. В любом случае для спора нужна платформа знаний предмета + опыт. Будешь спорить?

> Сусл © (21.11.07 19:06) [180]

> почему ты не хочешь сделать Runtime исключение?

Каким образом в этой конкретной ситуации сделать Runtime исключение?
Если вот таким:
try { ... } catch (IOException e) { throw new RuntimeException(...) }
то точно так же я могу возбудить и CloneNotSupportedException. Что именно возбуждать - это вообще не вопрос и не проблема. Проблема в том, что в любом случае будет подмена исключения - а это есть бред. И скажи - почему программеру навязывается вот такой бредовый стиль кодинга?

> C0s (21.11.07 19:59) [181]

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

Это ясно, что никто не запрещает сделать для создания клона вообще ЛЮБОЙ метод. Хоть конструктор, хот makeClone, хоть что угодно еще. И ясно, что заткнется этот компилятор как миленький, вместе со своими выкрутасами. Но с какой-такой радости я должен изобретать велосипед, ежели существует механизм, специально для того и сделанный? Только лишь потому, что механизм этот сделан через не то место?

Не верю. Понимаете, я не верю, что класс Object писали дураки. Наоборот, я не сомневаюсь, что его писали очень умные и очень опытные люди. И если они сделали именно так - значит, какой-то смысл в этом есть, что-то они в виду имели. Вот в ЭТОМ и хочется разобраться.

> за 5+ лет полёта на java мне ни разу вообще не довелось
> додуматься до использования метода clone

А мне ни разу не довелось писать 3D-игру. А кто-то только этим и занимается. Но не решает диффуров. А кто-то только их и решает. И что?

> Сусл © (21.11.07 21:12) [187]

Дим, огромное спасибо за ценный совет читать книги. Только это... видишь ли, Эккеля я как бы читал. И как бы далеко не раз. И что конструктор может в потомке стать недоступным - это я в курсе. Но не могу понять - а почему и зачем так сделано? Неудобно ведь.

Вот в данном конкретном случае - никто не мешает написать потомка CloneNotSupportedException и объявить в нем конструктор с параметрами (String, Throwable). И все завернется, как миленькое. Но остается тот же вопрос - порождать потомка класса лишь для того, чтобы сделать доступным нужный конструктор - это есть бред. И почему этот бред мне навязывают? Что, модель ООП для джавы дураки придумывали? Не верю. Тогда чего они хотели этим скрытием конструкторов добиться?

А насчет того, что у джавы философия есть - может, и есть. Но слова твои прозвучали, тем не менее, голословно. Потому что оттого, что кто-то перевел "Thinking in Java" как "Философия Java", никакой философии еще не возникло - а никаких других доказательств ты не привел.

То, что броско названо какой-то там "философией" называется на самом деле проще, понятнее и конкретнее - "реализованная модель ООП". И она есть в ЛЮБОМ ОО-языке, потому что иначе не бывает. Ну так вот - некоторые аспекты этой реализации в Jav"е выглядят, как минимум, недостаточно продуманными. Что очень странно - и в чем и хочется разобраться.

Я уж не говорю о странной логике, когда отцы-основатели:

- с одной стороны, всячески пекутся, чтобы я не напорол ошибок (и указатели у меня отобрали, и сборку мусора организовали, и обрабатывать исключения меня аж силком заставлюют, и т.д.);

- а с другой строны, дают мне же в руки аффигительно мощные механизмы в виде reflection и АОП, с помощью которых я могу влезь практически куда угодно и начудить практически что угодно, в обход всех ООП вместе с их философиями.

> [198] Юрий Зотов © (22.11.07 10:05)

Ладно, про Эккеля извини. Читал - хорошо. Нет повода тебе не верить.

Не отвечая никакой конкретной твоей фразе я попробую ответить тебе в общем.

Каждый язык имеет свои особенности. При изучении очередного языка у тебя есть по сути 2 возможности:
1. Попытаться забыть, что знал из пред. языков и изучать новый язык с чистого листа.
2. Попытаться учить новый язык используя пред. знания.

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

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

Вот в java иначе сделано. Тебе ничего не остается, кроме как читать книги, читать филолософов java, смотреть и изучать чужие исходники и пытаться понять, почему так сделано.

Вот ты говоришь, что не веришь, что создатели Object дураки. А может они и дураки? Почему нет? Я, например, не имею четкого мнения по этому поводу. Согласись, что любому ублюдству можно найти оправдание. Если ты знаешь это оправдание, то ты в теме и перестаешь удивляться нелогичным на твой взгляд вещам. Тебе нужно просто понять и согласиться с нелогичностиями. Ну или идти обратно к нам, на Дельфи писать :)

Вообще, если тебе интересно пофилософствовать на тему Checked Exceptions, то тебе дорога на java форум на RSDN. Там есть любители пообщаться на тему философии java. Если и не ответят, то пошлют на буржуинский форум почитать на эту тему.

Извини, но странно выглядит твоя попытка обсудить это здесь, на форуме по дельфи. Тут java разработчиков мало. Вот iZen есть, но он же как пророк java среди дельфистов. Другие серьезные java разработчики сюда не ходят (простите, если ошибаюсь). Вот C0s заходил. Если интересно, то можешь с ним сцепится (если получится, конечно) на упомянутом выше RSDN. Могу тебя заверить, что он очень серьезный собеседник.

> Юрий Зотов © (22.11.07 10:05) [198]

> Но остается тот же вопрос - порождать потомка класса лишь
> для того, чтобы сделать доступным нужный конструктор - это
> есть бред.
Почему бред? Это "защита от дурака", гарантирующая корректность инициализации классов-потомков.

Похоливарим еще? (java, checked exceptions) Найти похожие ветки