NotGonnaGetUsНаследования и exception'ы (особенно checked) стыкуются слабо.
Ну или возвращаемся к некрасивой идее "почти каждый метод описан как throws Exception".

NotGonnaGetUsПринципы инкапсуляции могут быть легко нарушены при "тупом" пробрасывании эксепшинов вверх по стеку вызова или при их обработке.
Пожалуй что не уловил глубины мысли.

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

Сергей ИльичЕсли объект обнаружил себя изувеченным после неправильного порядка вызова его методов
То лично я бы вправил мозги программисту, проектировавшему и/или реализовывашему этот объект.

У объекта есть (может быть) состояние. Методы могут менять состояние. Если метод не в состоянии корректно изменить состояние, он должен оставить объект в исходном состоянии и выбросить исключение. Изувеченное состояние на входе означает, что некий метод "отработал нормально" и при этом оставил после себя изувеченный объект. То есть если переводить на аналогии с БД - разрушил целостность и выполнил commit.

Сергей Ильичлогировать. Через полгода посмотреть логи и обнаружить, что где-то возникает IndexOutOfBoundsException раз месяц, исследовать проблему и починить.
И пока не починили - полгода держать программистов без премий. За высокий профессионализм, выражающийся в любимой пользователями ситуации "нажимаю кнопку - и ничего не происходит. Даже сообщения об ошибке не пишет, зараза".

Сергей ИльичПо философии зачот. Не всегда внешний интерфейс в который надо завраппить свой код это позволяет.
Что именно - корректно изменить состояние? Сомневаюсь, признаться. Пожалуй даже готов дать математически строгое доказательство того, что любой объект, для которого существует "правильная" последовательность вызовов, может быть изменен так, чтобы корректно работать с "неправильной".

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

Сергей ИльичСмысла пробрасывать исключения до уровня хэндлеров кнопок лично я не вижу.
А кто говорит о пробрасывании? Они там иногда случаются. Хотя бы те самые, которые Вы собираетесь выуживать из логов.

NotGonnaGetUs
Я таки не понял, при чем тут нарушение принципов инкапсуляции в контексте именно "пробрасывания по стеку". Если говорить о "знании деталей чужой реализации", выражающейся в указании "чужих exception-ов", то эта проблема равно характерна для любого класса, где родительский метод вынужден описывать в себе throws, нафиг ему не нужные, но нужные в одном из дочерних классов. То есть это в чистом виде сказанное Вами в предыдущей фразе "наследование и checked exceptions плохо стыкуются". Что же до unchecked exceptions, то с ними я не вижу никаких проблем ни в наследовании, ни в приведенном Вами примере.

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

А они есть (с)анекдот.
Не верю (с) Станиславский.

Если использовать в данной ситуации unchecked exceptions придётся либо
а) знать детали каждой из реализаций используемого интерфейса (причём даже тех, что ещё не появились)
либо б) использовать exception только как флаг _произошла ошибка_ без какой-либо дополнительной информации позволяющей по разному обрабатывать разные ситуации.
Либо же в) писать обработку каждого исключения в подходящем месте. Там, где нужно обработать конкретное исключение - обрабатывать его. Остальные пускать дальше, возможно обработав по некоторой общей схеме, и знать, что другие, неизвестные части программы, обработают их так, как сочтут нужным.

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


Здесь основной является вторая строка - это собственно говоря текст, сгенерированный в месте исключения, методе например FileWriter.Open, а первая и третья строки - добавлены методами, допустим Application.SaveCfgFile и FileWriter.Write соответственно (cтек вызова в этом примере - SaveCfgFile -> Write -> Open).

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

Массовое же использование unchecked exceptions приводит к ситуации, которую вы описали словами "ставить трай-катч вокруг любого вызова библиотечного метода".
Я не припомню у себя таких слов, как минимум сказанных в этой теме. Мало того, я категорически не согласен с этим утверждением. Если Вы покажете мне, какую цитату имеете в виду - уверен, все окажется не так просто.

Если мне не изменяет память, в какой-то момент я говорил Вам, что концепция исключений в Яве в текущей реализации вместо помощи программисту мешает ему, поскольку даже если метод декларируется как не выкидывающий исключений, тем не менее он может выкинуть исключение и эту возможность надо предусмотреть. При этом сколь помню я показывал, что в JDK нет единой логики выкидывания исключений, что также усложняет жизнь. Возможно, Вы имели в виду именно эти слова - но тогда не надо приводить аргумент против checked exceptions как аргумент против unchecked exceptions.

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

При таком подходе checked exceptions только замедляют работу и вводят трудно уловимые ошибки связанные с сокрытием ошибок (пустой catch(){}).

Если же на передний план выходит вопрос надёжности, то время потраченное включение в проектное решение исключительных ситуаций себя вполне окупает.
Скажем так, я не ощутил, чем checked exceptions помогают надежности. Поработав в дельфе, где говоря джавовским языком, все exceptions unchecked, поработав на яве (и надеюсь, попрощавшись с ней), я не ощутил преимуществ checked exceptions, но сполна ощутил их неудобства. Прошу отметить, что в обоих случаях я работал над кодом повышенной ответственности (24x7 сервис в первом случае и ядро крупного сложного приложения во втором).

Никто не запрещает наследование exception'ов, что в сущности эквивалентно использовнию интерфейсов (заисключением множественного наследования).
В данном случае нужно именно множественное наследование, и в яве его единственным суррогатом являются интерфейсы. Давайте смотреть.

Допустим, у нас есть интерфейс IDataExchange и его реализации FileExchange, EMailExchange итп. Реализации склонны выбрасывать из себя соответственно FileException, EMailException итп. Вы хотите, чтобы из IDataExchange наружу шел некий универсальный класс исключения, то, что можно обработать без углубления в специфику класса исключения, некий DataExchangeException.

Наиболее идеологичное, что можно сделать в Яве для решения такой ситуации (в общем случае) - описать DataExchangeException как интерфейс; в реализациях описать соответственно наследников XXXXException, реализующих DataExchangeException, и возбуждать именно их. Правда, тут еще вылезет проблема, связанная с невозможностью реализовать helper, расширение, если исключение не возбуждается собственно реализацией, а получается ей из используемой библиотеки.

Это лучшее, что можно было бы сделать, но такого вроде как не удастся :(

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

Допустим, у нас есть цепочка использования: A -> B -> C. Объект C возбуждает некоторое исключение; класс A содержит его обработку. Если в классе B мы используем некий конвертер, мы тем самым должны в классе B знать, какая информация потребуется классу А, в то время как по идее, следовало бы просто передать транзитом любой объект и не думать о чужих проблемах. Последствия понятны: изменения в реализации А могут потребовать изменений в реализации конвертора, то есть в B.