уф..., осилил :)

softwarer
MemCheck крайне удобен для профилактики ошибок у кастомера раньше, чем они произойдут, хотя в его информацию стоит заглянуть и после того, но вопрос не в этом. Если посмотрите, он был упомянут в контексте возможности получить стек вызовов вне контекста исключения, просто стек для текущего момента - что, как я сейчас нашел, появилось в java только с версии 1.5.

А как же new Exception().getStackTrace() в 1.4, или
принт стектрейса в всвой стрим с последующей обработкой? :)

softwarer
Давайте тогда отмотаем чуть назад. Вы назвали throws логичным, поскольку она дает информацию о возможных исключениях. Хорошо. С моей точки зрения, например, абсолютно логичен вызов setModel (null). Почему-то этот логичный вызов вызывает exception, причем не NullPointerException, которого я мог бы ожидать по предыдущему опыту с JTree, но нечто другое. Информации об этом - нет, по крайней мере в throws. Мне все равно надо лезть в
исходники и проверять.


Давайте говорить не о том, чего нет нигде, а о том, что есть хоть где-то.

Или на пальцах:

перед вами класс#метод: SomeClass#setBlaBla(int a, int b, int c, int d);
(на любом языке, сути не меняет)

Вы видите его первый раз в жизни, вопрос:
Какие значения можно передать в этот метод и что будет если передать другие значения?

Знаете ответ? Может быть для java и delphi он как-то различается? Нет? Ну-ка, ну-ка.... хочу его улышать.

Мы с вами уже спорили на эту тему в форуме по java. Ну или покрайней мере пытались :)

В дельфи не силён, но, как я пронимаю, все эксепшины там "unchecked" в терминологии java.

Разделение же на сhecked/unchecked exceptions - палка о двух концах, т.к.

1. Оно предполагает знание неких "паттернов" (аналогичные знания необходимы для работы с методами clone, equals, hashcode, etc), следование которым приводит к надёжно работающему и устойчивому к случайным сбоям коду. Одна только не обходимость писать этот "дурацкий catch" уже плюс, т.к. вольно не вольно заставляет помнить, что существует что-то ещё кроме успешных сценариев работы приложения :)

2. Не знание паттернов приводит к рождению антипаттернов ( пустой catch, ловля errors, без дальнейшего пробрасывания и т.д.)

Но(!), по пути 2 идут те же люди, что игнорируют обработку "кода возврата", считая, что результат выполнения метода всегда успешен, либо отдают обработку ошибок на откуп среде выполнения (компилятору) принимающему решение за них, а поэтому эксепшины не могут принести в код больше вреда, чем их отсутсвие

А посему - не надо на них ругаться, их нужно понимать :)

Хочу сослаться на книжки:
"java без сбоев, обработка ошибок и ёклмн" http://www.ozon.ru/context/detail/id/2342758/,
и главу об обработке ошибок у Рихтера в ".NET Framework" http://www.ozon.ru/context/detail/id/2279035/.


Мне все равно надо лезть в исходники и проверять.

Код сам писаться никогда не будет :)

Можно развить тему борьбы с NPE (@Nullable, etc), вполне похвально и разумно пытаться выявить такие вещи в компил тайм.
Но есть же ошибки другого типа (элементарный пример метода, где не понятно, что и как передавать я привёл). Тут всё равно придётся изучить библиотеку перед тем как её использовать - грустно, но факт %)

Если повезёт, и документация будет полной - отлично, иначе - в код и тестовые запуски. И никуда от этого не убежать - не важно на delphi, java или ином диковинном языке написан код - вины эксепшинов в этом нет. Они только помогают, как могут, справиться с "нелёгкой" программерской участью %)

Буду краток :)

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

Нет, вы доказывали, что cчитать объявления exception'ов заменой "лазанья по исходникам" нельзя. (Я правильно понял?)

Я же, как и sun, говорю, что они предназначены не для этого (затем и отсылал к книжкам). Цель эксепшинов не сигнализация о не корректности аргументов, а оповещение об исключительных, но *ожидаемых* событиях (например, потеря соединения с базой данной). В отличии от кодов возврата, их нельзя проигнорировать "неосознанно" или "от рассеяности".

Наследники RuntimeException, Error и (боже упаси) прямые наследники Throwable выполняют уже другую функцию.
Это, главным образом, средства диагности проблем для программиста.

Понимаю, тут можно приводить примеры библиотек, где "злой дядя" заставляет обрабатывать RuntimeException на ровне с Exception и нарушает "общественный договор" другими способами :)

Хочу только сказать, что ничто не мешает "хорошему дяде" рисовать окошко с ошибкой ручками (забавно было бы пытаться это сделать в консольном приложении для линух без иксов :)) и вести логи при помощи того же log4j или стандартного в java с версии 1.4. механизма, избавляя пользователя от не обходимости что-то куда-то зарисовывать.

Не далай зла сам и его станет меньше в мире (с) Л.Н.Толстой в вольной обработке :)


Если бы throws и/или еще что-нибудь решали бы эти проблемы - я был бы очень рад. Но ведь не решают - просто приходится писать лишнее. И - то, к чему я отношусь намного хуже - маскировать суть, функциональность, нагромождением технических деталей.


Скупой платит дважды. Что тут можно ещё сказать?
Нанимаешь дешёвую рабочую силу, не хочешь её обучать - трать деньги на решение возникающих проблем в будущем.


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

А истина... абсолютной истины не существует, это знают все %)

softwarerБоюсь, в данной цитате я отвечал только на первую часть Вашего примера, где Вы строили примерно тот же пример, что и я.

Cорри, не понял ответа %)

softwarer
Хм. В первую очередь, я не понял, что Вы имели в виду, и чтобы не задавать кучу поясняющих вопросов, попросил бы Вас переформулировать максимально однозначно, в частности выделив: цель exception-ов или директивы throws, оповещение или принуждение, оповещение кого....


Хм...

Давайте попробуем.

Начну из далека.

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

Эти "технологии", очевидно, имеют свои недостатки. А именно:

1. трудночитаемый и усложнённый код из-за неявной НЕОБХОДИМОСТИ через строчку вставлять проверки кодов возврата.

2. коды возврата в виде "простых" типов не несут достаточно информации о "проишествии", возникает не обходимость создания велосипедов ака методов getLastErrorDescription(), возврата каких-то сложных структур и т.п. усложнения, свои в каждом приложении.

3. поскольку не всегда возможно разрешить "особую" ситуацию в месте её возникновения (решение может зависить от контекста в котором вызвается метод, внтури которого возникает эта ситуация), почти каждый метод ОБЯЗАН иметь код возврата(!). Если следовать этому принципу, то согласно п.1. сколько-нибудь сложный код станет вообще не подъёмный, если не следовать - это приведёт к сокрытию причин ошибок.

Всё вместе - это умноженный на тысячу случай, когда вместо Строки метод возвращает null. Пойди разбери почему null - толи аргументы не верные, толи сетевой шнур кто-то выдернул...

Вобщем жить с этим конечно можно, но только очень аккуратным/педантичным людям :)

Исключения упрощают труд программиста.

1. В случае однотипной обработки ошибки:
вместо получаем
2. Исключения предоставляют УНИФИЦИРОВАННЫЙ механизм доставки инфрмации об исключительных ситуациях. Эта информация влючает в себя место возникновения, причину ошибки и любую другую полезную информацию для человека-отдачика и существенно упрощает исправление ошибок.

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

Это были общие положения. Если перейти к системе исключений в java, то мы увидим что существует три разновидности исключений:

- Error extends Throwable
- Exception extends Throwable
- RuntimeException extends Exception

Первый класс включает ОШИБКИ относящиеся к среде исполнения в целом, например, OutOfMemoryError, VirtualMachineError, StackOverflowError, ConfigurationError.
Это ошибки, игнорирование которых приводит к НЕПРЕДСКАЗУЕМЫМ последствиям. Как будет работать колеченная VM никто не знает :) Если их ловят, то главным образом затем, чтобы выполнить необходимые завершающие действия и переслать выше по стеку, но никак не для того, чтобы перепрятать в консоль или лог файл (кроме тех редких случаев, когда действительно ясно, что нужно сделать чтобы исправить ситуацию).

RuntimeException (unchecked exceptions) - тоже используется для обозначения ОШИБОК, но уже ошибок программых. Их возникновение не нарушает работу среды исполнения.
В отличии от NoClassDefFoundError, после NullPointerException работать вполне себе можно :) Однако это ОШИБКА. Толи программист не правильно использует какой-то код (пытается читать поток после закрытия, засунуть null в качестве аргумента метода и т.д.), толи другой программист написал кривой метод, потому что тоже чего-то забыл или не учёл (толи звёзды так сошлись).

А вот Exception (checked exceptions) - это уже не ошибка. Это "Особая Ситуация, Которая Требует Обработки".
Например, СlassNotFoundException - это вполне ожидаемый результат попытки загрузить класс по имени, IOException - логично, что чтение из потока может прерватся по какой-то причине.
Заметьте, их возникновение не является следствием ошибки программиста (в отличии от ClassCastException, рантайм эксепшина который может возникнуть если я вдруг решу, что некий Object это ни что иное как MyBestObject и влеплю в код каст), ошибкой становится их игнорирование программистом (путём вставки пустых catch'eй, неоправдованное прокидывания в родителя (особенно обернув его перед этим в рантаймэкспешин(!)) и т.п.)
Если в думаться, то Exception это дополнительное значение возвращаемое методом, и как любое возвращаемое значение оно должно быть объявлено. Именно для этого используется директива throws - объявляет, что одним из возвращаемых значений метода является некий Exception.

И всё казалось бы хорошо, но возникает вопрос: а кто будет обрабатывать RuntimeException'ы?

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

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


Писать "общие рецепты" дело неблагодарное, но куда деваться... надеюсь я вызился достаточно однозначно :)



... На уровне базового окна есть метод refresh(), вызываемый по кнопке "обновить данные", ну и соответственно в зависимости от движка - в одном случае грозит SQLException, в другом - допустим, BIBeansException, итп. ...

В данном случае напрашивается добавление создание
класса RefreshFailedException extends Exception и
объявление его в методе refresh().
Код вызывающий метод refresh уже сам должен решить, что делать с этой ошибкой. Точнее програмист, который его пришет :)


Захотели? Ну извините, значит садимся и снова прописываем все исключения refresh-а во все места этой бизнес-функции. Получаем полный идиотизм: функция движка A возвращает исключение, относящееся к движку B, потому что оно может быть результатом refresh-а.
...
...


Cогласитесь, разница с RefreshFailedException велика :) На полном серьёзе.

На счёт желания проигнорировать обработку исключения переслав его выше по стеку, если на самом деле его можно обработать в точке получения, полностью согласен - это bad practice, который "легко делается".
Но влюбом случае такой поступок не хуже, чем окно с сообщением и последующим завершением программы. Для меня.



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

Конечно лучше, но использование того что "хуже", вовсе не причина писать таком же уровне :)



Почему swing - потому что эта часть обсуждения пошла с моей фразы про то, что awt/swing выводят свои исключения в консоль. То есть для пользователя это выглядит как "нажал на кнопку - и ничего не произошло" (приложение не падает, работает дальше).

Вот оно как...
Осталось только разобраться в чём причина: в архитектуре Swing или руках разработчика, который не правильно его приготовил :)
Хотя согласен, было бы приятно, если бы готовка заключалась в простом подогреве :)

Можно сказать? Можно сказать, что недешевая рабочая сила хорошо напишет и без throws. Для нее это - необходимость писать дополнительные слова и ничего больше. Для дешевой рабочей силы, судя по процитированному, это тоже не подходит.
Ну, осталось решить вопрос, какая из недешёвых рабочих сил дешевле: та, что умеет без throws или та, что умеет со throws и которой очень тяжело получается без него? %)

Но лучше не решать, а посмотреть как оно на практике получится :)

Так зачем же оно нужно?
Чтобы был мир во всём мире :)

Исключения не идеал, но и говорить что в них нет ничего хорошего тоже нельзя.

Ситуация, как с использованием наследования в ооп. Вроде бы и просто всё, но нужно много раз подумать прежде, чем делать. Причём думать нужно на этапе проектирования приложения %)

Ewg_а вот еще вопрос,
насколько просто в java реализовать раскраску строк/ячеек грида (табличка со скроллом), в зависимости от находящихся в них значений ?

ФОрум по java в другом месте.
Задавай такие вопросы там.

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


Ну и что? Точно также существует прекрасно читаемый код написанный с кучей GOTO. Разве этот факт означает, что с goto проще и легче писать хороший код? Это значит только то, что человек способен учиться на своём и чужом опыте, вырабатывая "паттерны" эффективного поведения. В том числе эвристики как потрогать goto, что бы оно при этом не воняло :) Нужно только задуматься - а сколько же времени на это обучение уходит?

Аналогично с кодами возврата. Я чёрным по белому писал выше:
NotGonnaGetUs
жить с этим[кодами возврата] конечно можно, но только очень аккуратным/педантичным людям


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

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


Архитектура приложения зависит, в том числе, и из методов обработки ошибок. Если код просто "переписывался", то такой результат в полне объясним. Очень странно пытаться применять старые приёмы в работе с новыми технологиями...

Кстати, чтобы переписывать работающий код должны быть веские причины... какие были в ваших случаях? :)

c129
Что касается приведенного примера, то тут кое-кому следует либо сначала подучить матчасть, либо воздерживаться от категорических заявлений по предмету, в котором слабо разбирается. Тот же код может выглядеть, например, примерно так:


Не разобрался c тонкими намёками: кому нужно подучить матчасть? :)

c130


Это называется пример легко читаемого кода? Я хотел написать с начала именно такую конструкцию, но потом подумал, что если я так поступлю, мне скажут, что я спецаильно всё усложняю %)

c131

И почему это хуже чем
?
По-моему как минимум не хуже.

А теперь двайте разберёмся.

Почему fooC вернул -1?
варианты:
- ошибка в методе А
- ошибка в методе В
- ошибка в методе С
- входные данные для метода А не верны (от куда-то же он берёт значение)
- входные данные для метода В не верны
- входные данные для метода С не верны
- произвольная комбинация выше перечисленного...

В случае же FooException мы получаем точное место, где произошла ошибка.
Глянув на нужную строчку кода мы увидим, что было не так:
толи проверка аргументов не прошла, толи какое-то из допущений в коде fooX() оказалось не верно; а главное мы будем знать в каком из этих трёх методов возникло исключение.

Собственно вы предложили недостающую иллюстрацию к тезису:
NotGonnaGetUs
Если следовать этому принципу, то согласно п.1. сколько-нибудь сложный код станет вообще не подъёмный, если не следовать - это приведёт к сокрытию причин ошибок.

softwarer NotGonnaGetUs
Хм. Осилил. К сожалению, меня несколько огорчило то, что начав издалека, Вы в итоге ответили совсем не на заданный вопрос, суть которого - в следующей процитированной фразе.

NotGonnaGetUsИсключения не идеал, но и говорить что в них нет ничего хорошего тоже нельзя.


Тоже - хм %)

Отвечал я на следующее:

Хм. В первую очередь, я не понял, что Вы имели в виду, и чтобы не задавать кучу поясняющих вопросов, попросил бы Вас переформулировать максимально однозначно , в частности выделив: цель exception-ов или директивы throws, оповещение или принуждение, оповещение кого....



softwarer
Думаю, Вы не сумеете отыскать место, где я бы говорил "в исключениях нет ничего хорошего" либо нечто подобное.

Каюсь, слегка заигрался в словах.

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


softwarer
NGGU
В данном случае напрашивается добавление создание класса RefreshFailedException extends Exception и объявление его в методе refresh().
Угу. И потребуется упаковка в него SQLException, BIBeansException и прочих, которые от RefreshFailedException никак не унаследуешь.


Нет, не так. SQLException, BIBeansException и т.д. - это просто cause для refreshFailed.
Например,

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

По порядку...

c127То Вы обещали непременно либо нечитаемый либо плохо работающий код (" Если следовать этому принципу, то согласно п.1. сколько-нибудь сложный код станет вообще не подъёмный, если не следовать - это приведёт к сокрытию причин ошибок. "), ...

Вы сами подтвердили этот тезис своим примером. Ваш код - скрывает причины ошибок.

..., то оказывается что это не страшно, код может быть хорошим и читаемым, просто нужно быть аккуратным:


Да, нужно быть аккуратным, нужно тратить массу времени на то, чтобы разрешать сложности перечисленные под пунктами 1-2-3 в посте выше, вместо того, чтобы тратить свою аккуратность на описание собственно логики приложения.

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

Конечно, код в котором НЕТ ошибок не страдает от того, что их СКРЫВАЮТ.

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

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

Как следствие открывается ниша для "так себе программистов" и новые технологии служат для компенсации понижения "общего скила".
Пусть это кому-то и не нравится, но в нашем идотском мире решение остаётся за деньгами, поэтому армия формоклпателей будет жить на тех пор, пока их работа приносит реальную прибыль (отчего-то никто не пытается сэкономить кучу денег посадив 125 программистов за ассемблер, чтобы сделать GUI к БД столовой N5).

Одним словом, ситуация такова: "мастер якимыч сделал топором матрёшку за день", а "пьяный васька настрогал 100 матрёшек на станке за пол дня". Привсём не уважении к ваське и любви к якимычу, нельзя не признать, что матрёшки ваське делать проще и экономически выгоднее :)


c127
NotGonnaGetUs
жить с этим[кодами возврата] конечно можно, но только очень аккуратным/педантичным людям
....
Точно также существует прекрасно читаемый код написанный с кучей GOTO


А неаккуратных программистов вообще не бывает.

Угу, вопрос в том, кто на что тратить свою аккуратность и прочии умения.
Всё тот же якимыч и васька.


c127 В джаве создается впечатление, что можно программировать неаккуратно ... Особенно плохо когда на это покупаются при обучении. По этой причине относительное количество хороших программ на С по-моему больше чем на джаве.
Домохозяйки за уши к программированию на С не притягиваются.


Это отдельный вопрос, к исключениям отношения не имеющий, но всё равно интересный.

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

Но причём тут домохозяйки и С ?!
Всё, что верно при программировании на С, верно и при программировании на ассме, басике, паскале, джаве - только на практике приходится помимо трудностей "алгоритмических" вникать в трудности языка.
А кому нужны лишнии трудности? Грузинскому комсомолу?



c127
Я вроде такого нигде не говорил о дилетантах. А что, у Вас есть примеры хорошего джава-кода (или любого другого), написаного дилетантами?

Вот и я про тоже. Код ядра писали далеко не дилетанты, но есть уйма задач (которые рождает рынок), где можно использовать "уже не дилетантов, но ещё не профи (или уже никогда не профи? :))".

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

Может быть сила привычки?

c127
От плохих программ пользы все равно мало. Лучше иметь мало хороших, чем много плохих.

Не все определяется соображениями оптимальности программирования, часто делаются неоправданные действия, есть же еще маркетинг. Например появление C# с точки зрения технологий ИМХО неоправдано, чистый маркетинг.

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

Маркетинг... У C# есть очень агрессивные стронники, главным образом среди людей, которые достаточно долго писали на С++. Это получается жертвы рекламы? :)


c127
NotGonnaGetUs
Почему fooC вернул -1?

Не знаю. У Вас он вернул -1 и у меня он вернул -1. Задача была построить код эквивалентный Вашему. Она решена.
У меня было два *не* эквивалентых примера один с исключениями, другой без. Пример с кодами возврата и в вашем, и в моём варианте одинаково хорошо демонстрирует его не достатки перед кодом с исключениями, для которого вы не привели эквивалентна...