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

Всегда, когда в данном методе невозможно обработать ошибку, при этом дальнейшее выполнение невозможно.

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

ёмко... +1

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

Это сообщение отредактировал(а) Den1s - 24.8.2007, 08:34

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

• Все почти в порядке - JOptionPane.INFORMATION_MESSAGE
• Нехорошо, но поправимо - JOptionPane.WARNING_MESSAGE
• Непоправимо, но ошибка частая и причина ее скорее юзер - JOptionPane.ERROR_MESSAGE
• Что-то совсем дурное - остановка программы по исключению.

Это сообщение отредактировал(а) _Y_ - 24.8.2007, 09:32

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

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

Это идеальный вариант. К сожалению, не помню названия книги, в которой доволно детально была описана проблема. Сколь помню идея такова:

 У Макконела в "Совершенном коде" довольно неплохо тема раскрыта

Хорошо задаю наводящий вопрос в форме жизненной задачи.
Например, вы написали свой класс унаследованный от TabbedPaneUI, который в заисиовсти от текущего L&F работает по разному. Теперь перед вами стоит вопрос как поступить, если установленный пользователе L&F отличается от тех, что вы обрабатываете в своем TabbedPaneUI? Как бы поступили вы? При ответе примите во внимание, что в вашем проекте может быть множество классов, которые переписывают интерфесы разных GUI компонент.

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

Это сообщение отредактировал(а) y3u - 24.8.2007, 15:44

А как насчёт Double.parseDouble(java.lang.String stringToParse)?
Я всегда использую такую конструкцию:


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

Добавлено через 14 минут и 21 секунду
Упс, я извиняюсь.
Кажется я не совсем правильно понял суть изначального вопроса.

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

надо место в коде использовать эргономично... 



я так мыслю, если бы мы открывали какие-либо потоки, которые могут нам бросить какой-нить эксцебшон, то вполне уместно обернуть их try/catch и finally, в последнем мы все открытое должны прибить, апосля можно бросать какой-нибудь эксцебшон, желательно своего собственного типа, а как его там навихру у Карлсона будут или не будут отбрабатывать - не наша забота...

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

1. Вроде бы тема использавать-не использовать исключения, а не обрабатывать-не обрабатывать  Но это, конечно, софистика и придирки  

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

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

Постулирую:
Конечный пользователь, пользующийся production app не должен знать ни о каких исключениях с этим вроде бы все согласны
Среда обязана работать и выполнять свои функции до тех пор пока она их выполнять не сможет
В случае ошибки внутри приложения она должна оставить какой-то след, чтобы потом разработчик смог разобрать откуда растут ногу у возникшей проблемы
 
Проблема номер 1 Я не случайно привел пример с L&F. Дело в том, что если какая-то кнопка не может отрисоваться, используя какой-либо L&F она обязана отрисовываться хоть как то.
Проблема номер 2 Взгляните на этот вопрос с точки зрения дизайнера или архитектора. 

1) Почему какая то кнопка должна завязываться на какой-то Exception? 
2) Если ответ на вопрос номер 1 положительный, то на какой именно Exception? 
3) Что если вы не можете переписать сигнатуру метода для того чтобы он выбрасывал UnsupportedLookandFeelException или какой-либо другой? 
4) Должен ли в таком случае класс "кнопки!!" узнать о каком-то логгере? 

Как бы вы ответили на эти вопросы?

1. Если неэк переписать сигнатуру, выбрасывается RuntimeException.
2. В java с версии 1.5 можно ловить необработанные исключения. На поток устанавливается обработчик.
3. ВСЕ классы могут/должны знать о логгере.
4. Рассчитывать на определённый LnF нельзя, пишите свой. Если не хотите его изменения, делайте свои компоненты, которые не будут использовать LnF.

Можно пример, пожалуйста.

Maksym, имеется в виду Thread.setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)

nornad
Ясно, спасибо.