Проверена спецификация исключений и шаблон стратегии

Question

Я разработчик на C ++, и я довольно новичок с проверенным и непроверенным исключением в Java. Спецификации исключений в c ++ просто не хороши, и поэтому никто не использует их. Мне нравится проверенное исключение, и у меня есть вопрос, давайте иметь этот интерфейс:

public interface Warehouse {
   MyStuff fetch(int id);
}

Хранилище может быть реализовано по-разному: файл, база данных или память (макет объекта для теста).

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

Я вижу два решения:

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

2. Выполните всю работу в конструкторе класса реализации и оставьте функцию выборки неспособной выбросить. Мне нравится этот способ, объект существует и является действительным или не существует. Единственный недостаток этого подхода заключается в том, что мы не можем реализовать ленивую оценку; нам нужно прочитать и разобрать файл в конструкторе, хотя никто не будет использовать объект. Это не эффективно.

Я что-то упустил? Есть ли лучший способ избежать этой проблемы?

Answer 1

Ваше первое решение - правильное. Измените ваш интерфейс на:

public interface Warehouse {
    MyStuff fetch(int id) throws FetchFailureException;
}

И заставьте каждый подкласс обернуть свой IO, JDBC или любое другое исключение в FetchFailureException. Это исключение FetchFailureException должно быть во время выполнения, если оно не подлежит восстановлению, и проверяться, если оно подлежит восстановлению.

Answer 2

Я бы предложил вам включить в класс Warehouse все исключения, а затем работать с подынтерфейсами для работы с непроверенными исключениями, например:

public interface Warehouse {
  MyStuff fetch(int id) throws FileNotFoundException;;
}

public interface FileWarehouse extends Warehouse {
  @Override
  MyStuff fetch(int id) throws FileNotFoundException;
}

public interface OtherWarehouse extends Warehouse {
  @Override
  MyStuff fetch(int id);
}

Answer 3

Рекомендуется указывать исключения, которые будет вызывать метод в интерфейсе.

Предположим, у вас есть пользовательский класс Exception:

Класс MyException расширяет Exception
{
public MyException (String message)
{super (message);
}

public MyException (строковое сообщение, причина исключения)
{
super (сообщение, причина);
}

}

Обработка всех ваших исключений в классе MyException,

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

хранилище открытого интерфейса
{

public MyStuff fetch () выдает MyException;

}

Answer 4

Лично я хотел бы, чтобы Warehouse перечислил все исключения, которые он может выдать (включая непроверенные в javadoc)

Если у вас есть исключение, которого нет в списке, вам нужно обработать его или обернуть.(Независимо от того, проверено оно или нет)

Вы должны решить, хотите ли вы, чтобы Warehouse выдал проверенное исключение или нет.Вы не можете иметь это в обоих направлениях.(На самом деле вы можете, но это не очень хорошая идея, поскольку вы можете вслепую генерировать проверенное исключение без ведома компилятора)