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

← →
Romkin © (2007-11-19 12:40) [120]

> вот, теперь в новой версии операционки в методе А может
> появляться исключение E2. Что делать со всеми методами,
> которые используют А?

Тебе же сказали: так писать нельзя :)))
Что значит "может появляться"? Ты просто так не напишешь, не скомпилируется

← →
Petr V. Abramov © (2007-11-19 12:44) [121]

> Romkin © (19.11.07 12:40) [120]
вот и получается, что exception надо либо гасить, либо выдавать его за что-то описанное.
Так и рождаются программы с сообщениями "ошибка ввода-вывода. позовите сисадмина, желаем ему всего хорошего"

← →
Romkin © (2007-11-19 12:56) [122]

> вот и получается, что exception надо либо гасить, либо выдавать
> его за что-то описанное.Так и рождаются программы с сообщениями
> "ошибка ввода-вывода. позовите сисадмина, желаем ему всего
> хорошего"

Ты не понимаешь, это и называется "Думать на Яве"! :)

← →
Petr V. Abramov © (2007-11-19 12:58) [123]

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

← →
Romkin © (2007-11-19 13:00) [124]

Я, например, так и не могу представить, зачем мне может понадобиться проверять путь прохода исключения. И чтобы компилятор мне в этом помогал.
Это к iZEN © (16.11.07 23:19) [89]

← →
Petr V. Abramov © (2007-11-19 13:07) [125]

в общем гадость эта java Ж)
http://top.rbc.ru/wildworld/16/11/2007/126059.shtml
:)

← →
DiamondShark © (2007-11-19 13:21) [126]

> Юрий Зотов © (16.11.07 10:40) [16]
> > mephasm (16.11.07 10:31) [14]
>
> > Не понимаю в чем вы видите проблему.
>
> Напишите потомка парсера, перекройте его метод parse и попробуйте
> выбросить из него... ну, к примеру, SQLException. Увидите.

А нафига пользователю XML парсера какие-то SQLException? Он и слов-то таких не знает.

← →
Romkin © (2007-11-19 13:34) [127]

> А нафига пользователю XML парсера какие-то SQLException?
> Он и слов-то таких не знает.

Во-во. Точно. Заглушить, чтобы и не знал!

← →
Anatoly Podgoretsky © (2007-11-19 13:36) [128]

> Petr V. Abramov (19.11.2007 13:07:05) [125]

Она для другого уровня программистов, с другими мозгами.

← →
Petr V. Abramov © (2007-11-19 13:37) [129]

> DiamondShark © (19.11.07 13:21) [126]
а он этот XML может читать из потока, а поток из blob.
и юзер получает сообщение "парсер не парсит" вместо "database connection failed"

← →
Petr V. Abramov © (2007-11-19 13:47) [130]

смысл уловить, конечно, можно - если он парсер, то и должен по-правильному поднимать EParseException. Только вот таких правильных проектировщиков - да на саппорт посадить бы.

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

Петр, ты про агрегацию слышал?

← →
Petr V. Abramov © (2007-11-19 14:27) [132]

> Сусл © (19.11.07 14:21) [131]
слово умное. наверняка слышал, только не знал, что это агрегация. А что? :)

← →
euru © (2007-11-19 14:58) [133]

> Petr V. Abramov © (19.11.07 12:58) [123]

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

А как же быть в виртуальных функциях со списком передаваемых параметров, их типами, типом возвращаемого значения? Их вроде бы тоже в потомках изменять нельзя.

← →
Petr V. Abramov © (2007-11-19 15:15) [134]

> euru © (19.11.07 14:58) [133]
никак не быть, жить с этим :)
но это заголовок, который слабо влияет на то, как реализована эта функция.
Ф-ция базвого класса может быть вообще абстрактной. А что throws абстрактная ф-ция? Да что угодно.

← →
kaif © (2007-11-19 15:56) [135]

Предлагаю в Джаву добавить еще один модификтор метода: depricated или obsolete.
:)

← →
Petr V. Abramov © (2007-11-19 15:59) [136]

фактически определение ф-ци (параметры, типы и т.д) - это контракт на то, ЧТО будет делать ф-ция.
А throws - неявный контракт на то, КАК она это будет делать, что абослютно противоречит идее ООП.

← →
euru © (2007-11-19 16:14) [137]

> Petr V. Abramov © (19.11.07 15:15) [134]

> никак не быть, жить с этим :)
А что мешает так же относиться к исключениям?

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

> А что throws абстрактная ф-ция?
Абстрактная функция декларирует список исключений, которые могут выбросить потомки. Точно так же, как и список параметров, которые могут использовать потомки.

← →
Petr V. Abramov © (2007-11-19 16:21) [138]

> euru © (19.11.07 16:14) [137]
> А что мешает так же относиться к исключениям?
да ничто не мешает, можно и мух с котлетами с одну кучу свалить.

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

> Абстрактная функция декларирует список исключений, которые могут выбросить потомки
а кроме как с потолка его этот список есть откуда взять?

← →
euru © (2007-11-19 16:28) [139]

> Petr V. Abramov © (19.11.07 15:59) [136]
Определение функции декларирует какие параметры будут на входе и какие на выходе функции. А что она будет делать и как именно она будет делать, зависит от реализации функции и может не совпадать с первоначально планируемым смыслом.

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

← →
Petr V. Abramov © (2007-11-19 16:30) [140]

вот есть у меня базовый класс с методом "нарисуй собачку"
метод можно хоть через OpenGL реализовать, хоть через движок Doom. Там и там exception`ы разные.
Выходов 2:
- везде подымать EDogError с сообщением "не будет тебе собачки, почему - сам догадайся"
- потратить уйму времени на обезьянью работу - перехват EDoom и преращение его в EDog, притом что от этого он реально в EDog не превращается.

← →
euru © (2007-11-19 16:44) [141]

> Petr V. Abramov © (19.11.07 16:30) [140]
А можно в общих чертах сценарий, как бы это реализовывалось в Delphi? Особенно при вызове этого метода.

← →
Petr V. Abramov © (2007-11-19 16:53) [142]

> euru © (19.11.07 16:44) [141]
что знаю - обрабатываю, что не знаю - raise.
Нельзя и не надо обрабатывать ВСЕ, как правило, с низких уровней идут довольно информативные сообщения, которые помогут если не юзеру, то для диагностики.

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

P.S. всем до вечера

← →
iZEN © (2007-11-19 20:32) [143]

> Petr V. Abramov © (19.11.07 12:02) [118]
>
> > Romkin © (19.11.07 11:57) [117]
> вот, теперь в новой версии операционки в методе А может
> появляться исключение E2. Что делать со всеми методами,
> которые используют А?

Переписывать.

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

2ПетрАбрамов.

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

Я был бы очень ращ, если бы компилятор меня заставил отреагировать на новый побочный эффект. Вот возьми он и скажи "Слыш программист, я знаю, что вот эта функция может вести теперь иначе, причем я знаю даже как - может выдать новое исключение! Что делать то будем? Куда ставить то (с)".

Ты будешь просто вынужден подумать над ситуацией, что само по себе не плохо.

А думать оно всегда полезно, Петр.
(с) ИШ :р

Да тут повышается ответственность разработчика библиотеки. Может оно и неплохо? Как там - семь раз отмерь...

← →
Mystic © (2007-11-19 21:32) [145]

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

Ну и что? Такое случается раз в год, два раза на пасху. Вообще, в Delphi блоки try...except были у меня скорее экзотикой. Исключение пролетает весь стек вызова функций, чтобы преобразоваться на самом верху в красивый диалог об ошибке либо в возвращаемый код ошибки и ее описание.

Схема, когда исключительные ситуации используются как средство управления в программе обычно рождают спагетти, сравнимые с goto в Fortran-е :)

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

← →
Сусл © (2007-11-19 23:48) [146]

> Mystic © (19.11.07 21:32) [145]

вот скажи - ты аккуратно пишешь комментарии к коммитам в своем репозитарии (ну там suversion, cvs, vss, starteam - что юзаешь, не знаю)?

← →
Petr V. Abramov © (2007-11-20 00:19) [147]

> Сусл © (19.11.07 21:04) [144]
> А думать оно всегда полезно, Петр.
И мне полезно, и тебе полезно, и (с) полезно и ИШ полезно и :р полезно :)
недодумали. или пока думали, путч случился.
исправить ничего нельзя

потомоу что
> iZEN © (19.11.07 20:32) [143]
> Переписывать

или остаться с своем уме, или разойтись по домам, или
> Petr V. Abramov © (19.11.07 01:18) [104]
шкуру индийскго тигра, сосуд с водой из реки Ганг, и трехъядерный ноутбук в полной камасутрой в электронном виде с видеопособием :)

← →
Petr V. Abramov © (2007-11-20 00:51) [148]

> euru © (19.11.07 16:28) [139]
>
> > Petr V. Abramov © (19.11.07 15:59) [136]
> Определение функции декларирует какие параметры будут на
> входе и какие на выходе функции. А что она будет делать
> и как именно она будет делать, зависит от реализации функции
> и может не совпадать с первоначально планируемым смыслом.
>
>
> Точно так же список исключений декларирует всего лишь, какие
> исключения может выбросить функция. Не более.

так не делают, по крайней мере в Delphi :)))
контракт на "что делать" должен выполняться.
ф-ция Draw должна рисовать либо геом фигуры, либо баланс. Несмотря на схожесть названия.

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

Вот у меня есть класс

TAnyThingDBLoader
function LoadSomeThingFromDB: pointer // :)
function GetPass: string;

function LoadSomeThingFromDB: pointer; // :)
begin
apass := GetPass ;
try
Connection.Connect(pass);
except
on E: EDBError do
case E.DBErrCode of:
-1017: raise EInvalidPassword;
-2808: raise EPasswordExpired;
else raise;
end
end;
// загрузить someThing
end;

продолжение следует

допустим, в данном случае GetPass запрашивает пароль у юзера и оборабатывает все исключения.
А в следующем проекте мне понадобилось пароль брать из ini-файла. А у меня есть класс TIniFileReader, купленный, стыренный, самонаписанный, главное, хороший, и сграмотной обработкой исключений.
Вроде бы имеет смысл его использовать для доставания пароля из ini-файла.
Но нифига: он поднимает TIniFileException.
Что делать? Загадка: на C начинается на paste кончается

Mystic © (19.11.07 21:32) [145] +10! Разумеется. except в Delphi - экзотика.
Тем более удивительно, что в java, это, похоже, стиль жизни...

> вот скажи - ты аккуратно пишешь комментарии к коммитам в
> своем репозитарии

Как того требует соглашения по проекту. Если я один, то обычно и так помню что к чему :)

> Разумеется. except в Delphi - экзотика.

Потому что дядя постарался и написал:

procedure TWinControl.MainWndProc(var Message: TMessage);
begin
try
try
WindowProc(Message);
finally
FreeDeviceContexts;
FreeMemoryContexts;
end;
except
Application.HandleException(Self);
end;
end;

кстати, посчитайте try..except в модулях Forms и Controls. это к вопросу о стиле жизни.

Да, дядя постарался и сделал перехват там, где надо. На верхнем уровне. Теперь практически и не делаю :)
А экзотика - по сравнению с finally. Их явно побольше будет

Мне кажется, что создатели Java вкладывают несколько иной смысл в понятие Exception, нежели создатели Delphi.

В Delphi Exception - это именно "исключительная ситуация". Какую ситуацию считать исключительной, решает разработчик приложения или компонента.

А в Java это ближе к понятию "потенциальная ошибка" или "потенциальный сбой ресурса". Поэтому в Delphi искючительная ситуация зачастую обретает свой смысл лишь в контексте всего приложения, а в Java обречена интерпретироваться локально, в контексте вызывающего класса.

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

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

Фактически в Java мне пришлось бы на уровне вызова SQL-команды породить исключение нового типа (осмысленного для пользоваателя), хотя в этом контексте такая интерпретация пока еще совершенно абсурдна. Или ввести целую иерархию интерпретаций разного уровня, каждый раз порождая новый тип исключительной ситуации. К чему столько мучений?

Мне проще создать один класс исключительных ситуаций, в котором описать все варианты при помощи кода ошибки (а иногда для этого достаточно и нативного кода ошибки SQL) и потом интерпретировать это все в одном месте, на самом верхнем уровне приложения. Это удобно и в Дельфи все приспособлено для такого решения, и при этом не возбраняется сделать так, как в Джава, если это хочется.

Разница между архитектурой кода классов и архитектурой кода исключительных ситуаций в том, что для классов важно поведение, а для исключительных ситуаций - интерпретация.

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

Разработчик приложения, юзающий компонент, оказывается в ситуации, когда его принуждают интерпретировать исключительные ситуации, которые он не намерен вообще никак интерпретировать, так как в его конкретном случае эти ситуации могут вообще быть исключены. Например, он решил предварительно проверить существование файла, прежде, чем его открывать. Для него требование учесть то, что файла уже может на месте не оказаться, так же абсурдно, как если бы кто-то принудил его заключать в try catch всякий раз простую конкатенацию строк ради перехвата случая превышения ими ограничения на размер памяти компьютера.

И он видит в этом принуждение, а не просто требование.

Не всякое требование есть принуждение. Так, требование объявлять типы переменных не есть принуждение, ибо программист объявляет их по мере надобности для себя и для решения своих проблем, а вот требование обрабатывать всякое исключение, которое вздумал порождать автор компонента есть забота о проблемах и беспокойствах автора компонента и его надобностях, пусть даже они и сами по себе чрезвычайно серьезны в каких-то конкретных ситуациях.

Одним словом, мне кажется, что прежде чем применять принципы ООП к чему-то, нужно вспомнить чему они в конечном итоге призваны служить.

А призваны они служить упрощению повторного использования.

И если понятно, что имеется в виду под повторным использованием поведения, то не всегда это понятно, что иметь в виду под повторным использованием интерпретации.

Интерпретация ошибки типа "файл не найден" универсальна.
А вот интерпретация прочих исключительных ситуаций может сильно зависеть от контекста использования и даже от настроения конечных пользователей.

> [152] Mystic © (20.11.07 12:07)
> > вот скажи - ты аккуратно пишешь комментарии к коммитам
> в
> > своем репозитарии
>
> Как того требует соглашения по проекту. Если я один, то
> обычно и так помню что к чему :)

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

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

> моя имха такая - любое средство, которое приводит к повышению
> контроля за кодом есть гуд, в независимости от гиморности
> этого средства.

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

Примерно то же самое и в программировании. Можно пойти дальше и повысить контроль над кодом:
* ввести обязятельную декларацию всех классов и типов, которые может использовать данный класс
* ввести обязательную декларацию классов и методов, которые может вызывать данный метод
* перечислять все методы и поля предка, которые используются в этом классе
И т. д., думаю что список легко расширить. Но в такой системе любое незначительное изменение вызывало бы целую лавину сопутствующих изменений, что сделало бы работу над проектом просто невозможной.

> [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 не говорю, имхо отдельная тема.

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