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

← →
iZEN © (2007-11-16 20:22) [80]

Извиняюсь
/path/to/B.java:29: parseString(java.lang.String, AttributeList) in B cannot override parseString(java.lang.String, AttributeList) in A; overridden method does not throw java.io.IOException.
следует читать как:
/path/to/B.java:29: startElement(java.lang.String, AttributeList) in B cannot override parseString(java.lang.String, AttributeList) in A; overridden method does not throw java.io.IOException.

← →
iZEN © (2007-11-16 20:25) [81]

> Romkin © (16.11.07 16:01) [78]
>
>
> > > Использовать базовый Exception в декларации throw всех
> > ваших методов.и получить орден от индусского правительства
> > за такое кол-во дополнительных строк кода :)
>
> Да не надо ничего использовать. Показали же уже, что ограничение
> на исключения в заголове метода легко обходится. Оно просто
> не действует, было бы желание.

public class A { public void startElement(String name, AttributeList attrs) throws SAXException { try { if (name.equals("SCHEDULE")) { this.ParseStartSchedule(attrs); return; } return; } catch (IOException e) { throw new SAXException("I/O error: " + e.toString(), e); } catch (ScheduleParseException e) { throw new SAXException("ScheduleParseError" + e.toString(), e); } } ... }

Это не "обход". Проверяемое исключение SAXException всё же бросается. Компилятор пропустит этот код как валидный — контракт базового класса соблюдён.

А что было бы, если бы метод startElement был перегружен в потомке и в него долбавили бы throws IOException:
public class B extends A { public void startElement(String name, AttributeList attrs) throws SAXException, IOException { ... } ... }
Тогда ранее написанный класс, использующий объект базового класса A, не смог бы вызвать полиморфно метод объекта класса B только из-за того, что сигнатуры методов РАЗНЫЕ. (Компилятор включает в сигнатуру методов информацию о checked exceptions). Вообще же, javac выдаст ошибку при компиляции класса B:

/path/to/B.java:29: startElement(java.lang.String, AttributeList) in B cannot override startElement(java.lang.String, AttributeList) in A; overridden method does not throw java.io.IOException.

то есть использовать класс B и объекты в давно написанной программе, в которой определён класс A, будет невозможно. Программист класса A жёстко определил, какие исключения может бросать метод parseString и все перегруженные методы в будущих потомках класса A.

Чтобы "добавить" ещё одно проверяемое исключение программисту класса B, ему можно идти двумя путями:

1) Объявить потомка класса SAXException, например, IOSAXException и бросать экземпляр потомка:
throw new IOSAXException();

либо

2) "Завернуть" IOException в SAXException и бросить:
throw new SAXException("I/O error: " + e.toString(), e);
как уже было показано выше.

Контракт на полиморфные вызовы не нарушен. Программисты могут спать спокойно.

← →
Romkin © (2007-11-16 20:30) [82]

> 2) "Завернуть" IOException в SAXException и бросить:throw
> new SAXException("I/O error: " + e.toString(), e);как уже
> было показано выше.Контракт на полиморфные вызовы не нарушен.
> Программисты могут спать спокойно.

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

← →
Romkin © (2007-11-16 20:33) [83]

Точнее, что мне помешает объявить в заголовке метода свой тип, например, RomkinException, а внутри метода тупо оборачивать им все остальные?
Какой вообще смысл в этой стенке?

← →
iZEN © (2007-11-16 21:05) [84]

> Romkin © (16.11.07 20:33) [83]
> Точнее, что мне помешает объявить в заголовке метода свой
> тип, например, RomkinException, а внутри метода тупо оборачивать
> им все остальные?

Помешает компилятор. Для переопределённых методов нельзя указывать новые типы проверяемых исключений, которые не являются наследиками описанных ранее. То есть расширять базовый интерфейс метода нельзя, можно только сужать.

> Romkin © (16.11.07 20:33) [83]
> Какой вообще смысл в этой стенке?

Смысл в этой стенке такой: чтобы в будущем не ломалась логика вызовов ВСЕХ полиморфных методов ПОТОМКОВ. Чтобы не позволить бросать новые проверяемый исключения, которые не входят в иерархию уже определённых в методах БАЗОВЫХ классов, иначе весь смысл использования проверяемых исключений теряется. Смысл как раз в том, чтобы обеспечить проверку операций позднего связывания рантайма ещё на этапе компиляции.

Не нравится — пользуйтесь RuntimeException"s как в Delphi и .Net.

← →
iZEN © (2007-11-16 21:15) [85]

> Romkin © (16.11.07 20:30) [82]
>
>
> > 2) "Завернуть" IOException в SAXException и бросить:throw
> > new SAXException("I/O error: " + e.toString(), e);как
> уже
> > было показано выше.Контракт на полиморфные вызовы не нарушен.
>
> > Программисты могут спать спокойно.
>
> Все верно, я все так и понял. А теперь скажи, нафига вообще
> нужен этот контракт на объявление всех исключений, если
> он вот так вот легко обходится? Чтобы было?

Он и не обходится. Он всё же реализуется, но именно так, как разработчик считает нужным.

> Romkin © (16.11.07 20:30) [82]
> Почему просто
> не сделали его рекомендательным?

Тогда это бы не отличалось от использования RuntimeException"s — на то они и checked exceptions, чтобы проверяться на этапе компиляции, а не во время выполнения, когда проверять уже поздно, пользователь видит "AV". 50% ошибок программистов в этом плане компилятор не допустит.

> Romkin © (16.11.07 20:30) [82]
> Почему его вообще не убрать?
> И почему программисты могут спать спокойно, если он во втором
> случае просто не работает?

Что "не работает"? Как раз-таки работает. Исключение SAXException("I/O error: " + e.toString(), e); будет поймано вызывающим методом и обработано надлежащим образом. Строка ""I/O error: " + e.toString()" — это просто детали, которые дополняют исключение e. В вызывающем методе можно проанализировать исключение e, если это сочтёт важным сделать программист-пользователь этого класса. Информация достаточно полна и не потеряна.

← →
Romkin © (2007-11-16 21:21) [86]

> Тогда это бы не отличалось от использования RuntimeException"s
> — на то они и checked exceptions, чтобы проверяться на этапе
> компиляции, а не во время выполнения, когда проверять уже
> поздно, пользователь видит "AV". 50% ошибок программистов
> в этом плане компилятор не допустит.

Э. Так и так не отличается, мне только лишние телодвижения делать надо, оборачивать исключение в уже объявленное.
Вообще-то речь не об AV, не об ошибках RunTime, они-то, как я понял, идут по факту. А, например, об IOError. Пусть видит, что он файл удалил, или у него сетка отвалилась. :)
Если мне надо - я посмотрю на заголовок, и перехвачу нужное. А так-то зачем? Зачем мне перехватывать и оборачивать своим типом известие о том, что место на диске кончилось? Или что пользователь ввел неправильную дату?

← →
Romkin © (2007-11-16 21:25) [87]

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

← →
vpbar © (2007-11-16 23:07) [88]

читал, вспоминал яву. И вот какой вопрос возник. С какой основной целью было сделано это checked exceptions?
1. С целью документировать возможные исключения метода.
2. С целью ограничить возможные исключения метода.
3. Что бы гарантировать, что метод может бросить только определенные исключения. С тем чтобы можно было работать с методом базового класса, полагая, что он может кинуть только данные исключения, несмотря на то что за ним может скрываться какойнить дочерний класс.

Из всех вариантов я могу понять только последний. Ибо докуменировать можно иными средствами. Просто так ограничиать - вообще непонятно зачем надо.
Остается только одно. Возможность работать с тем же TStream, и иметь гарантию, что он может вызвать только исключения, например типа IOException. Не смотря на то, что за ним скрывается TFileStream или TMemStream. В принципе в этом есть некоторый смысл.
И можно найти (контр)аргументы для следующих заявлений:

>
> Но, с другой стороны: есть у меня, например, базовый класс
> TStream для потока... От него порождены TFileStream, TResourceStream
> и TSocketStream, которые, понятно, работают совершенно с
> разными источниками данных и поэтому сталкиваются с совершенно
> разными ошибками... Ну и что, методы базового класса должны
> учитывать все возможные исключения, что ли? А если появится
> новый источник данных с новыми типом исключений? Или надо
> предусмотреть одно исключение на все случаи жизни?

При работе с TStream вы можете ожидать IOExcaption, но ни как не все варианты типа FileWriteExcaption, ConnectExcaption и т.п. Т.е. вызывая в базовом методе TStream.CopyFrom полиморфный read вам абсолютно не нужно знать из-за чего конкретно возникнет ошибка чтения. И если при этом конкретная реализация возбудит ConnectExcaption то вы не сможете ее тут обработать (если конечно заранее не будете знать всех возможных предков их исключения). Т.е. спецефичные исключения нужны только в методах спецефичных для потомка. Для того же TSocketStream это может быть метод Conect.
С другой стороны checked exceptions это сильное ограничение и того же можно достичь просто опеределяя потомков IOExcaption и возбуждая только их. Но если нужно можно возбуждать другие исключения.

Вообщем интересно было бы, если обсуждение было продолжено и высказаны конкретные примеры, когда нужно возбудить исключение в переопределенном методе, которое не было объявлено в базовом. И кто его будет обрабатывать.
Это к Представим себе сторонний класс (или интерфейс), в котором объявлен какой-то метод.
из [0]

← →
iZEN © (2007-11-16 23:19) [89]

> Romkin © (16.11.07 21:25) [87]
>
> Или ты хочешь сказать, что все это затеяно только для одного,
> чтобы я сказал компилятору, что да, млин, видел я, что
> тут может быть это исключение?

Не только.
Компилятор может помочь отследить путь проверяемого исключения от места бросания до места его обработки и не ошибиться в расстановке "ловушек".

Если в приложении предусмотрена действительно хорошая обработка ошибок, то это очень качественное подспорье в таком деле. Как я уже сказал, 50% граблей с обработкой исключений берёт на себя компилятор. И только лишь за счёт применения (заметь, я не говорил "правильного" или "неправильного") проверяемых исключений! Это с одной стороны дисциплинирует программиста (навязывает стратегию контракта базового класса), а с другой стороны заставляет разработать собственную стратегию обработки исключений. Не ставить же везде "...} catch (Exception e) {}"! (хотя встречаются случаи, когда можно/нужно "гасить" проверяемое исключение, не обрабатывая и не пробрасывая его вверх по стэку вызовов).

← →
iZEN © (2007-11-16 23:34) [90]

> vpbar © (16.11.07 23:07) [88]
>
> читал, вспоминал яву. И вот какой вопрос возник. С какой
> основной целью было сделано это checked exceptions?
> 1. С целью документировать возможные исключения метода.

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

> vpbar © (16.11.07 23:07) [88]
> 2. С целью ограничить возможные исключения метода.
> 3. Что бы гарантировать, что метод может бросить только
> определенные исключения. С тем чтобы можно было работать
> с методом базового класса, полагая, что он может кинуть
> только данные исключения, несмотря на то что за ним может
> скрываться какойнить дочерний класс.

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

> vpbar © (16.11.07 23:07) [88]
> Из всех вариантов я могу понять только последний. Ибо докуменировать
> можно иными средствами. Просто так ограничиать - вообще
> непонятно зачем надо.
> Остается только одно. Возможность работать с тем же TStream,
> и иметь гарантию, что он может вызвать только исключения,
> например типа IOException. Не смотря на то, что за ним
> скрывается TFileStream или TMemStream. В принципе в этом
> есть некоторый смысл.

Во всём есть смысл, если есть желание его найти. ;)

← →
Alex Konshin © (2007-11-17 00:47) [91]

> Однокамушкин (16.11.07 09:12) [4]
> > Канадец (16.11.07 08:03) [1]
> > Дальше больше.... допустим идеальный вариант. Есть некий,
> > хорошо задокуменированый класс с виртуальным методом, который
> > чётко в документации указывает исключения какого рода он
> > может порадить. Дальше следуя Вашему второму варианту появляется
> > некто, кто пишет наследника, переопределяет данный метод
> > и плюёт исключение, которое нигде не упоминается в описании
> > базового класса. Вопрос: я, как пользователь базового класса,
> > какие исключения должен ожидать от этого метода?
>
> Нехорошо, конечно... Но, с другой стороны: есть у меня,
> например, базовый класс TStream для потока... От него порождены
> TFileStream, TResourceStream и TSocketStream, которые, понятно,
> работают совершенно с разными источниками данных и поэтому
> сталкиваются с совершенно разными ошибками... Ну и что,
> методы базового класса должны учитывать все возможные исключения,
> что ли? А если появится новый источник данных с новыми
> типом исключений? Или надо предусмотреть одно исключение
> на все случаи жизни? Но тогда обработка этих исключений
> будет сильно затруднена... В общем, я согласен с Юрием

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

В Java нечто новое не может кидать новые эксепшп просто потому, что компилятор не допустит. А кидать что ни попадя вообще дурная практика в любом языке. Вот, допустим, какой мне толк от самой ошибки чтения файла который кидает тот же TStream? Или, ещё более показательный пример: в каком-нибудь парсере получаем ошибку преобразования строки в число. Это мне практически ничего не даёт для нахождения причины ошибки. Мне-то нужно имя файла и номер строки, а ещё неплохо и позицию в строке, где это произошло.
Поэтому нужно оборачивать эксепшены в эксепшены более высокого уровня, а тот старый эксепшн указывать как cause. Тогда вы в распечатке стека этого исключения увидите что, где и когда случилось.

И это нужно делать не только в Java, а в Delphi тоже. Но, кстати, в Delphi в Exception нет поля cause, поэтому нужно делать свой класс, да и распечатку эксепшена приходится делать самому.
Кстати, в Delphi вообще плохо дело обстоит с поиском причин эксепшн. Нет печати стека вызовов при эксепшн.

← →
Petr V. Abramov © (2007-11-17 01:05) [92]

> Alex Konshin © (17.11.07 00:47) [91]
> поля cause,
можно попдробнее? жабу не знаю и знать не хочу :) но теологически интересно

> в Delphi вообще плохо дело обстоит с поиском причин эксепшн.
так в интерпретаторе-то проще по-любому, пусть p-code

← →
Германн © (2007-11-17 01:12) [93]

> Кстати, в Delphi вообще плохо дело обстоит с поиском причин
> эксепшн. Нет печати стека вызовов при эксепшн.

<offtop>
Ну это у кого как.
</offtop>
:)

← →
Petr V. Abramov © (2007-11-17 01:15) [94]

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

← →
Petr V. Abramov © (2007-11-17 01:16) [95]

+ Petr V. Abramov © (17.11.07 01:15) [94]
а может, и не в catch

← →
iZEN © (2007-11-17 08:17) [96]

Petr V. Abramov, вот тут посмотрите:

http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html

← →
Alex Konshin © (2007-11-18 00:30) [97]

> Германн © (17.11.07 01:12) [93]
> > Кстати, в Delphi вообще плохо дело обстоит с поиском причин
> > эксепшн. Нет печати стека вызовов при эксепшн.
> <offtop>
> Ну это у кого как.
> </offtop>
> :)

У меня тоже есть и когда-то делился здесь своим кодом для этого.
Но в любом случае это сложно, ненадёжно и информация ограничена.
В Java же всё есть в комплекте и ничего изобретать не нужно.

← →
Petr V. Abramov © (2007-11-18 00:41) [98]

> iZEN © (17.11.07 08:17) [96]
многа букаффф :)
за ссылку спасибо, сохранил, когда будет надо глубоко вопросом заняться, почитаю.
на [94] - [95] не могли бы в двух-трех строках ответить, они подразумевают протой ответ - "Да" - "нет"
ссылка [96] будет большим подспорьем для анализа краткого ответа.

← →
iZEN © (2007-11-18 14:36) [99]

> Petr V. Abramov © (18.11.07 00:41) [98]

Отвечаю.

> Petr V. Abramov © (17.11.07 01:15) [94]
>
> кстати, такой вопрос
> вот я в наследнике в catch вызываю ф-цию, которая тоже может
> поднять исключение, может, ф-ция своего класса, а может,
> другого. Исключения, которые поднимает вызываемая ф-ция,
> тоже в thows должны быть описаны или нет?

Да, должна быть описана в throws. Но можно перехватить в отдельном try/catch.

← →
iZEN © (2007-11-18 14:37) [100]

JLS в разых форматах: http://java.sun.com/docs/books/jls/

← →
Юрий Зотов © (2007-11-18 20:54) [101]

Что ж, ветка сползает вниз - значит, интерес к ней утрачен и можно, видимо, подводить итоги.

ИМХО, в целом провокация (а это, признаюсь, была все же провокация) более-менее удалась. Очень хорошо, что высказались люди, гораздо более сведующие в сабже, чем я и другие дельфисты. Надеюсь, почитать их посты всем нам было полезно - а еще полезнее, возможно, окажутся те ссылки, которые они привели. Спасибо, как говорится, за участие, да и за науку.

> mephasm

Надеюсь, Вы понимаете, что язвительный тон некоторых моих постингов был всего лишь реакцией на [5] и [11]. Поэтому обижаться, полагаю, не на что. Предлагаю забить и забыть.

:о)

← →
Petr V. Abramov © (2007-11-18 23:21) [102]

> Юрий Зотов © (18.11.07 20:54) [101]
а все равно наши победили :)

← →
Alex Konshin © (2007-11-19 01:04) [103]

> Petr V. Abramov © (18.11.07 23:21) [102]
> > Юрий Зотов © (18.11.07 20:54) [101]
> а все равно наши победили :)

В корне не согласен!

← →
Petr V. Abramov © (2007-11-19 01:18) [104]

> Alex Konshin © (19.11.07 01:04) [103]

> > Petr V. Abramov © (18.11.07 00:41) [98]
>
> Отвечаю.
>
> > Petr V. Abramov © (17.11.07 01:15) [94]
> >
> > кстати, такой вопрос
> > вот я в наследнике в catch вызываю ф-цию, которая тоже
> может
> > поднять исключение, может, ф-ция своего класса, а может,
>
> > другого. Исключения, которые поднимает вызываемая ф-ция,
>
> > тоже в thows должны быть описаны или нет?
>
> Да, должна быть описана в throws. Но можно перехватить в
> отдельном try/catch.

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

← →
Petr V. Abramov © (2007-11-19 01:24) [105]

> Petr V. Abramov © (19.11.07 01:18) [104]
> подымать exception жаба методе нельзя, если он не виртуальный
без НЕ ессно

← →
Petr V. Abramov © (2007-11-19 01:32) [106]

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

← →
Германн © (2007-11-19 01:41) [107]

> Petr V. Abramov © (19.11.07 01:32) [106]

Петя. Остановись. Успокойся и пойди спать.

← →
Petr V. Abramov © (2007-11-19 01:46) [108]

> Германн © (19.11.07 01:41) [107]
как-нибудь так и сделаю.
а по суи?

> а по суи?

Китайский язык не знаю ( а также и японский, вьетнамский и т.д.). Ты уж извини. :(

← →
J_f_S (2007-11-19 01:58) [110]

Petr V. Abramov © (19.11.07 01:46) [108]
> Германн © (19.11.07 01:41) [107]
как-нибудь так и сделаю.
а по суи?

Нутром чую, что опечатка. Но где? ;)

> где? ;)
ты ж программер, чужой код читать умеешь, сразу суть понимая :)))

> Petr V. Abramov © (19.11.07 02:11) [111]
>
> > где? ;)
> ты ж программер, чужой код читать умеешь, сразу суть понимая
> :)))
>

Он СИ-шник. Он так сразу не поймёт :)

> Petr V. Abramov © (19.11.07 01:18) [104]
>
> > > Petr V. Abramov © (17.11.07 01:15) [94]
> > >
> > > кстати, такой вопрос
> > > вот я в наследнике в catch вызываю ф-цию, которая тоже
> > может
> > > поднять исключение, может, ф-ция своего класса, а может,
>
> >
> > > другого. Исключения, которые поднимает вызываемая ф-
> ция,
> >
> > > тоже в thows должны быть описаны или нет?
> >
> > Да, должна быть описана в throws. Но можно перехватить
> в
> > отдельном try/catch.
>
>
> подымать exception жаба методе нельзя, если он <s>не</s> виртуальный.
> А если написать популярную библиотеку (opensorce ессно)
> и в другой ее версии поднять другой exception, хотя бы
> из соображений изменившегося многополярного мира - гарантирован
> орден от индусского правительства, чьи подданные будут за
> деньги переделывать заголовки миллионов методов

Работающий пример можно?

← →
J_f_S (2007-11-19 02:36) [114]

> Германн © (19.11.07 02:17) [112]
> > Petr V. Abramov © (19.11.07 02:11) [111]> > > где?
> ;)> ты ж программер, чужой код читать умеешь, сразу суть
> понимая > :)))
> Он СИ-шник. Он так сразу не поймёт :)

Немного иначе:
Он СИ-шник. Он сразу не так поймёт ;)

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

Ты неправ. Этого не может быть именно из-за того, что все чекед эксепшн должны быть объявлены. То есть проблемы не существует.

> Alex Konshin © (19.11.07 07:51) [115]
еще раз по полкам, интересно все ж, что в мире творится

есть метод А, который throws E1.

и есть метод B, который вызывает А.
у В throws E1 прописано должно быть?

> у В throws E1 прописано должно быть?

НАсколько я понял, либо прописываешь, либо внутре его перехватываешь.

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

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

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

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