Java, вернуть новое MyException: анти-шаблон?

Question

В моем классе я делаю проверку пользовательских данных.Многие условия применяются.При любом сбое я хочу выдать конкретное исключение MyException.Бросок этого MyException принимает много общих параметров и один пользовательский параметр (основанный на фактическом сбое).Таким образом, фактический бросок требует много символов для записи и разрушает аккуратность из-за дублирования кода.Также я должен бросить это слишком много раз.Я решил создать приватный метод, который подготавливает и возвращает новый экземпляр этого MyException и принимает в качестве параметра только пользовательские данные, поэтому код может быть намного чище.

private MyException createMyException(final CustomErrorData errorData)
{
... some info gathering, parameterizing, etc... 
return new MyException(errorData);
}

...

Итак, создание нового MyException намного короче:

throw createMyException(errorData);

Мой вопрос: какова правильная практика предотвращения дублирования кода в этом случае?Возможно, я преувеличиваю исключения.

Answer 1

An Фабрика исключений - никогда раньше не видел, но, по крайней мере, звучит как правильный дизайн.

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

Обычно выбрасываемое исключение - «только для журналов».Произошло то, чего не должно было случиться в текущем контексте.Что-то, разработчики должны знать и исправлять в следующем выпуске.Мы не должны использовать исключения для обработки ожидаемых состояний.

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

Answer 2

Если у вас есть одно общее исключение, вы потеряете некоторые из преимуществ ООП.

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

У вас будет что-то вроде этого:

try{
    //code here
}
catch (MyException ex){
  switch(ex.exceptionType){
     case IOException: doSomething();break;
     case ConnectionException:doSomethingElse();break;
     default: //throw the exception outwards if you don't want to process it
 }
}

Когда вместо этого у вас должно быть что-то вроде

try{
    //code here
}
catch (IOException ex){
    doSomething();
    }
catch (ConnectionException ex){
    doSomethingElse();
}

что более понятно и более ООП.

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

Answer 3

Я бы разделил две проблемы.Ваш класс знает, как собирать информацию, но не должен знать об исключении (пользователь этой информации).

Сначала определите метод для создания CustomErrorData экземпляра:

private CustomErrorData createCustomErrorData() {
    // info gathering
    return new CustomErrorData(something);
}

Затем определите конструктор для исключения, которое использует CustomErrorData:

public MyException(CustomErrorData errorData) {
    // save it as a field
}

затем

throw new MyException(createCustomErrorData());

там, где вам это нужно.

Это также позволяетвы должны использовать CustomErrorData для чего-то другого, например, для регистрации, отображения для пользователя, чего угодно.

Answer 4

Я бы бросил исключение в методе, если это не смущает компилятор.

private void throwMyException(final CustomErrorData errorData) {
... some info gathering, parameterizing, etc... 
    throw new MyException(errorData);
}

throwMyException(errorData);

или

private MyException throwMyException(final CustomErrorData errorData) {
... some info gathering, parameterizing, etc... 
    throw new MyException(errorData);
}

throwMyException(errorData);
// or if the compiler complains
throw throwMyException(errorData);

Answer 5

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