Выбрасывание исключения не определено в интерфейсе

Question

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

Вот пример:

public interface Reader 
{ 
    public abstract void read() throws IOException; 
} 

public class CarrotReader implements Reader 
{ 
    public void read() throws IOException {} 
} 

public class CupcakeReader implements Reader 
{ 
    public void read() throws IOException, CupcakeException {} 
} 

В этом случае, у вас есть определенное исключение, которое происходит при чтении кексов, так что вы хотите бросить исключение, связанное с этим. Однако Reader не определяет этот тип исключения в своем интерфейсе, так что вы делаете? Кроме того, это не имеет смысла, чтобы добавить CupcakeException к бросает пункт в Считыватель интерфейсу , так как этот тип исключения является специфичным для CupcakeReader. Один из способов: Читатель определяет так, чтобы он выдавал некоторый родительский тип, например Исключение, но затем вы теряете контекст для исключения. Что вы должны делать в этой ситуации? Благодаря!

---

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

Для наглядности, вот еще один пример:

public interface Reader 
{ 
    public abstract void read(); 
} 

public class CupcakeReader implements Reader 
{ 
    public void read() throws CupcakeException {} 
} 

В этом случае, вы не можете изменить чтения, но вы хотите, чтобы указать, что проблема возникла в CupcakeReader «s чтения метод.

Answer 1

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

... catch(CupcakeException e) { 
    throw new IOException("The sky is falling", e); 
} 

Answer 2

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

Answer 3

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

Answer 4

Если создать более высокое абстрактное исключение, которое работает в качестве базового класса для CupCakeException вы не связывать чтения интерфейса к конкретной реализации, как вы будете делать, если вы добавили CupCakeException к интерфейсу Reader. Если вы не допустили, чтобы одно исключение наследовалось от другого, в классе исключений есть класс constructor, который принимает забрасываемый второй аргумент, такой как Thorbjørn Ravn Andersen, который уже показан в его примере с коротким кодом. Это позволяет вам генерировать более абстрактное исключение, и каждая часть вашего кода, которая должна знать больше, а затем просто «есть ошибка», может искать причину более высокого исключения.

Answer 5

Только не используйте проверенные исключения.

Пример, который вы показали, является одной из причин, по которым проверенные исключения являются плохими.

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

Таким образом, вместо:

Value value = reader.read(); 

Вы вынуждаете его сделать это:

Value value = null; 
try { 
    value = reader.read(); 
} catch (Exception e) { 
    // now what?? 
} 

value.doSomething(); // potential NPE here 

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

EDIT:

Я удивлен, с отрицательным рейтингом. Есть люди, которые все еще считают, что проверенные исключения велики? Если так вот некоторые ссылки, почему вы не должны использовать проверенные исключения:

• Ни одна современная структура не использует проверенные исключения (Spring, EJB3 и т.д.)
• Статьи с примерами кода here
• StackOverflow topic
• Эффективное Java (разделы 58 и 59) - here

Answer 6

Исключение является частью интерфейса. Определите родительский родитель для всех ваших исключений в интерфейсе, если вы можете переопределить интерфейс.

Вы также можете сделать CupcakeException ребенком исключения IOException.