java - 用 RMI 链接异常是个坏主意？

Question

在抛出 RemoteExceptions 时使用异常链是个坏主意吗？我们有一个 RMI 服务器可以执行如下操作:

public Object doSomething() throws RemoteException
{
    try
    {
        return getData();
    }
    catch (CustomException ex)
    {
        throw new RemoteException(ex);
    }
}

我的客户端出现由 ClassNotFoundException 引起的 UnmarshallException。从好的方面来说，事实证明 CustomException 本身是导出的。不幸的是，这个家伙内心深处的另一个异常没有被导出，这就是 ClassNotFoundException 出现的地方。我认为层次结构是这样的:

RemoteException -> CustomException -> SQLException -> NotExportedException

我看到的问题是，即使我们可以保证导出 CustomException，我们也不能保证导出任何较低级别的异常。

因此，我倾向于从不使用带有 RemoteExceptions 的异常链接。相反，我认为我应该在服务器端记录堆栈跟踪并抛出一个普通的普通 RemoteException，没有链接到它的“原因”异常。有人处理过这种情况吗？

Answer 1

与其将 CustomException 包装在 RemoteException 中，不如像这样修改远程接口(interface):

interface Foo extends Remote {

  Object doSomething() throws CustomException, RemoteException;

}

这里的原则是只有 RMI 运行时应该引发 RemoteExceptions；它们表示远程处理失败，而不是应用程序逻辑失败。事实上，具体实现甚至不需要声明RemoteException。

但是，这无法处理您的服务从某些第三方库捕获异常但又不想在 throws 子句中公开该异常的情况。

public Object doSomething() throws CustomException {
  try {
    return theirSvc.getData();
  } catch (ThirdPartyException ex) {
    throw new CustomException("Failed to obtain requested data.");
    // or: throw new CustomException("Failed to obtain requested data.", ex) ?
  }
}

在这种情况下，我建议您不要创建“有漏洞的抽象”，在这种情况下，将在客户端中创建依赖项，否则无需了解该第三方库。

通常，记录和 抛出是不好的做法，因为相同的错误会被重复记录。但在这种情况下，我认为这是合理的，因为抛出的异常被传输到客户端；在客户端和服务器上记录它可能很有用。所以 catch block 最终看起来像这样:

catch (ThirdPartyException ex) {
   String message = "Failed to obtain requested data.";
   log.error(message, ex);
   throw new CustomException(message);
 }

这样，ThirdPartyException 依赖项仅限于服务器，服务器日志包含适当的特定于实现的信息，并且错误会正确地报告给客户端。