softwarerБоюсь, в данной цитате я отвечал только на первую часть Вашего примера, где Вы строили примерно тот же пример, что и я.
Cорри, не понял ответа %)
softwarer
Хм. В первую очередь, я не понял, что Вы имели в виду, и чтобы не задавать кучу поясняющих вопросов, попросил бы Вас переформулировать максимально однозначно, в частности выделив: цель exception-ов или директивы throws, оповещение или принуждение, оповещение кого....
Хм...
Давайте попробуем.
Начну из далека.
До появления концепции исключений для обработки ошибок и не стандартных ситуаций во всю использовался подход под названием "код возврата", а так же простое "падение программы с созданием coredump" ;)
Эти "технологии", очевидно, имеют свои недостатки. А именно:
1. трудночитаемый и усложнённый код из-за неявной НЕОБХОДИМОСТИ через строчку вставлять проверки кодов возврата.
2. коды возврата в виде "простых" типов не несут достаточно информации о "проишествии", возникает не обходимость создания велосипедов ака методов getLastErrorDescription(), возврата каких-то сложных структур и т.п. усложнения, свои в каждом приложении.
3. поскольку не всегда возможно разрешить "особую" ситуацию в месте её возникновения (решение может зависить от контекста в котором вызвается метод, внтури которого возникает эта ситуация), почти каждый метод ОБЯЗАН иметь код возврата(!). Если следовать этому принципу, то согласно п.1. сколько-нибудь сложный код станет вообще не подъёмный, если не следовать - это приведёт к сокрытию причин ошибок.
Всё вместе - это умноженный на тысячу случай, когда вместо Строки метод возвращает null. Пойди разбери почему null - толи аргументы не верные, толи сетевой шнур кто-то выдернул...
Вобщем жить с этим конечно можно, но только очень аккуратным/педантичным людям :)
Исключения упрощают труд программиста.
1. В случае однотипной обработки ошибки:
вместо
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
boolean error=false;
int valueA = fooA();
if (valueA !=- 1 ) {
int valueB = fooB(valueA)
if (valueB!=- 1 ) {
if (fooC(valueB)=- 1 ) {
error = true;
}
} else {
error = true;
}
} else {
error = true;
}
if (error) {
Sout("Sorry, чё-то не так :( ");
}
Sout("Bye!");
получаем
1.
2.
3.
4.
5.
6.
7.
8.
try {
fooC(fooB(fooA()));
} catch (FooException fe) { //вместо возврата "-1" кидается FooException
LOGGER.warn("sorry, ошибочка вышла...", fe); //как тут поступить
//зависит от конкретной логики реализуемой методами foo...
} finally {
Sout("Bye!");
}
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-а.
...
public void refresh() throws Exception
...
Cогласитесь, разница с RefreshFailedException велика :) На полном серьёзе.
На счёт желания проигнорировать обработку исключения переслав его выше по стеку, если на самом деле его можно обработать в точке получения, полностью согласен - это bad practice, который "легко делается".
Но влюбом случае такой поступок не хуже, чем окно с сообщением и последующим завершением программы. Для меня.
Ничто. Ничто не мешает хорошему дяде самому написать все, что надо для комфортной работы - библиотеки, компилятор... Но лучше, когда уже сделано.
Конечно лучше, но использование того что "хуже", вовсе не причина писать таком же уровне :)
Почему swing - потому что эта часть обсуждения пошла с моей фразы про то, что awt/swing выводят свои исключения в консоль. То есть для пользователя это выглядит как "нажал на кнопку - и ничего не произошло" (приложение не падает, работает дальше).
Вот оно как...
Осталось только разобраться в чём причина: в архитектуре Swing или руках разработчика, который не правильно его приготовил :)
Хотя согласен, было бы приятно, если бы готовка заключалась в простом подогреве :)
Можно сказать? Можно сказать, что недешевая рабочая сила хорошо напишет и без throws. Для нее это - необходимость писать дополнительные слова и ничего больше. Для дешевой рабочей силы, судя по процитированному, это тоже не подходит.
Ну, осталось решить вопрос, какая из недешёвых рабочих сил дешевле: та, что умеет без throws или та, что умеет со throws и которой очень тяжело получается без него? %)
Но лучше не решать, а посмотреть как оно на практике получится :)
Так зачем же оно нужно?
Чтобы был мир во всём мире :)
Исключения не идеал, но и говорить что в них нет ничего хорошего тоже нельзя.
Ситуация, как с использованием наследования в ооп. Вроде бы и просто всё, но нужно много раз подумать прежде, чем делать. Причём думать нужно на этапе проектирования приложения %)
