Представим, что у нас есть интерфейс:


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

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



Вопрос хорошо так поступать или плохо? Есть какие-нибудь советы по этому поводу?

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

Разработчик не бог, может быть и дураком.

Все зависит от контракта метода readStrings(), по хорошему даже RuntimeException надо декларировать.

Смысл RuntimeException состоит в том, что их можно избежать если провести проверку входных данных.

LSD, Я чисто из безграмотности хочу спросить, который раз уже встречаю выражение "контракт", что под этим имеется ввиду? Что такое контракт метода?

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

Возьмем для примера Iterator.remove(), там описывается, что этот метод делает, как меняется состояние коллекции, в каких случаях возможны эксепшены. Обрати внимаение, хотя оба эксепшера runtime, но тем не менее они описаны в контракте интерфейса. И значит любой кто будет реализовывать этот интерфейс, должен его соблюдать.

LSD, Спасибо!

Royan, вопросы правомерные, и развернуый ответ на них может потянуть на хорошую монографию. Но я постараюсь все же покороче 

Сначала быстрый ответ: да, в ситуации, которую ты обрисовал, оборачивать в нечекнутое и пробрасывать наверх - это нормальное решение.

Теперь немного поподробнее. Как бы мы ни стремились к идеалу, но жизнь есть жизнь, и зачастую приходится работать с тем что есть. Например, с некими API'ями, над которыми мы не властны. Вот у нас есть интерфейс с методом readStrings, который не объявляет никаких исключений. А нам надо писать его имплементацию. И мы точно знаем, что нам предстоит иметь дело с методами, которые выбрасывают IOException. И что нам остается делать? А ничего другого - только оборачивать в один из типов RuntimeException и пробрасывать в таком виде. Ну не глотать же его, в самом деле - уж это-то точно будет самым никудышным вариантом.

Пуристы могут возразить: но ведь тем самым мы нарушаем контракт! Ведь автор API'я такого не предусматривал?

Спокойно, бабуся - ответим мы. Что значит не предусматривал? Вообще, какие у автора могли быть выборы? Ну, допустим, объявить некое общее чекнутое исключение типа IOException. Было ли бы это как-то полезно юзерам либы? Парадоксальный ответ - НЕТ!

Как показывает практика, и к чему приходят наиболее продвинутые Java-мыслители, чрезмерное увлечение чекнутыми исключениями только засирает API и провоцирует разработчиков фактически игнорировать их, используя универсальные уловители и обобщенные объявления.

Вот допустим у нас есть метод, который инстанциирует класс по имени: Class.forName(someName).newInstance().

Какими только чекнутыми исключениями нас не пугают в этой короткой записи! И ввод-вывод, и безопасность, и классовая непоноценность. Но есть ли нам какое-то дело до того, почему у нас не создался объект? Можем ли мы в этот момент что-то поправить? Практически никогда! Но метод, внутри которого происходит все это безобразие, должен что-то делать с той дюжиной исключений, которые могут вылетать из его потрохов. Неужели выносить все эти объявления в сигнатуру метода? Но там, откуда это вызывается, тем более понятия не имеют, как реагировать на IllegalAccessException! Поэтому разработчик сделает одно из двух:



или



В английском это называется "defeat the purpose", что в волном переводе звучит как "за что боролись, на то и напоролись".

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

Взять хоть тот же метод Iterator.remove(). Разве не может в какой-нибудь из его (потенциально бесчисленных) реализаций вылететь на рантайме какой-нибудь ArrayOutOfBoundsException или NullPointerException? Да запросто! И хоть разработчик, использующий итератор, должен держать в уме возможность получения официально объявленного IllegalStateException, не стоит забывать, что и другие рантаймные исключения также возможны - и соответственно структурировать свой код.

Поэтому выводы, вкратце:

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

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

Вот.