Организация классов исключений в Java

Question

У меня есть много классов исключений. F.e .: InvalidMethodParameterException, EntityNotFoundException и т. Д. У всех есть код типа xxx.yyy.zzz и литерал описания. Вопрос: есть ли какие-либо рекомендации и методы для организации классов и его кодов/литералов. Пока я делаю это, чтобы поместить все коды и литералы в другие классы и даже файлы свойств ((.) Это выглядит очень дружелюбным, потому что, чтобы добавить одно исключение, я должен сделать другие изменения в других файлах, а не один И для исключения исключения я использую класс со статическими методами, который их бросает. Эти методы и подходы не создаются мной, а где я работаю. Поэтому я хотел бы предложить другие более эффективные подходы. Например, когда я предлагается использовать просто хранить каждое исключение буквальным и код внутри своего класса, они просто игнорировали говорят, что это unefficient и плохая практика.

Любая помощь будет оценена!

Answer 1

Вы можете централизовать их все в один класс, который бы положить все в один внешний класс:

public OurExceptionsClassTM { 

    static final String 
     ERROR1 = "123.acd.243", 
     ERROR2 = "124.axd.543", 
     ... ; 

    public static class InvalidMethodParameterException extends Exception { ... } 
    ... 

    public static throwSpecialException(){ ... } 
    ... 

} 

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

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

Answer 2

Я бы сказал, что системная архитектура, которая способствует эффективности разработчика, намного превосходит тот, который способствует эффективности выполнения, поскольку первый может легко охватить последний. Если внесение изменений в один модуль требует, чтобы вы открывали и изменяли несколько модулей, дизайн не повышал эффективность разработчика. My very favorite programming book рекомендует, чтобы типы исключений были мотивированы обработчиками исключений. Что-то вроде следующего:

Version 1: 
void tryToDoSomething(bool arg) { 
    try { 
     doSomething(arg); //Throws MyException 
    } catch (MyException e) { 
     if (e.errorMessage == "Try a different argument") 
      tryToDoSomething(!arg); 
     else if (e.errorMessage == "Try again") 
      tryToDoSomething(arg); 
    } 
} 
Version 2: 
//Split the exception so that it can be handled differently 
void tryToDoSomething(bool arg) { 
    try { 
     doSomething(arg); //Throws InvalidArgumentException, NotReadyException 
    } catch (InvalidArgumentException e) { 
     tryToDoSomething(!arg); 
    } catch (NotReadyException e) { 
     tryToDoSomething(arg); 
    } 
} 

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

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