Question

这次我有一个非常简单的“架构”问题。

假设我们有两个API，一个是“外部”，另一个是“内部”。对于他的每个方法，外部的实现，在它所做的其他事情中调用内部的方法（它是方法的1对1映射，每个远程方法具有相应的内部方法）。

附加信息：外部接口用@Remote注释，内部接口（开发业务逻辑）用@Local注释。

出于异常处理我的想法是创建两个例外：一个内部，一个外部。当然，外部的将包装内部，就像服务一样。

在代码中说，情况是这样的：

@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

有一件事，当你说API时，你应该参考一个接口。你的方法非常干净，希望这两种服务都实现相同的界面。

Answer 2

我的想法在这个问题上非常主观。

这样的设计让我认为异常被认为是一种天然的pheneomonen，应该定期捕捉并处理。

直接引自Joshua Bloch：顾名思义，例外是仅用于特殊条件;它们永远不应该用于普通的控制流程

我想跟随这些约定并尝试尽可能使用常规例外。过度使用异常和过度复杂的异常标准通常会使开发人员首先远离使用它们。当然，我并不是说所有与业务相关的异常都可能被一个标准的异常所包含，但我经常会看到代码如：

...
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原则的坚定支持者，我绝不会选择将它们分开。如果我首先选择使用它，我的自定义异常就已经很少使用了。我觉得分离增加的很少定义异常情况的价值，并增加了更多的样板。

所以将其包装起来，尽可能使用标准的内置异常，仅在可恢复流中捕获异常，而不是用于控制和验证，在涉及异常时尽量保持简单。

嵌套JAVA API的简单异常处理

2 个答案: