Простая обработка исключений для вложенных API JAVA

Question

У меня есть довольно простой «архитектурный» вопрос на этот раз.

Предположим, что у нас есть два API, один «внешний» и один «внутренний». Реализация внешнего, для каждого из его методов, вызывает между прочим, что он делает, правильный метод внутреннего (это 1 на 1 сопоставление методов, каждый удаленный метод имеет внутренний) ,

Дополнительная информация: Внешний интерфейс аннотируется с помощью @Remote, а внутренняя (где разработана бизнес-логика) аннотируется с @Local.

ДЛЯ ОБРАБОТКИ ИСКЛЮЧЕНИЯ моей идеи был создать 2 исключения: один внутреннего и один внешнего. Конечно, внешний будет обертывать внутренние, как это делают службы.

Говоря в коде, ситуация такова:

@Stateless 
public class RemoteServiceBean implements RemoteService 
{ 
    @Inject BusinessService businessSrv; 
    public method1(external parameters) throws RemoteException 
     { 

      try 
      {  
       bar();   
       businessSrv.method1(internal parameters); 
      } 
      //catch exceptions (also LocalException) and throws RemoteException 
      catch(Exception1 | LocalException ... e) 
      { 
       Logging.... 
       throws RemoteException(e,e.getMsg()); 
      } 
     } 
} 

@Stateless 
public class BusinessServiceBean implements BusinessService 
{ 
     public method1(internal parameters) throws LocalException 
     { 
     try 
      {  
       foo();   
      } 
      //catch exceptions and throws LocalException 
      catch(Exception1 | Exception2... e) 
      { 
       Logging.... 
       throws LocalException(e,e.getMsg()); 
      } 
     } 
} 

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

Все советы приветствуются.

Спасибо!

Answer 1

Мои идеи очень субъективны по этому вопросу.

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

Цитата прямо из Джошуа Блоха: Исключения составляют, как следует из их названия, до использовать только для исключительных условий; они никогда не должны использоваться для обычных управляющий поток

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

... 
public void getEntityById(Long id) 
{ 
    ... 
    if(id == null) 
    { 
     throw new BusinessRelatedConventionCompliantException(
       1,4,TYPE.CORE_BUSINESS,"Entity id can not be null"); 
     ... 
    } 
    ... 
} 

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

... 
public void getEntityById(Long id) 
{ 
    ... 
    if(id == null) 
    { 
     throw new IllegalArgumentException("Entity id param can not be null"); 
     ... 
    } 
    ... 
} 

Исключение только незаконного аргумента, по-моему, многократно игнорируется.

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

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

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

Answer 2

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