远程方法的例外情况

Question

远程方法异常的最佳做法是什么？

我确信您需要在远程方法实现级别处理所有异常，因为您需要在服务器端进行记录。但是之后你应该怎么做？

你应该在RemoteException（java）中包装异常并将其抛给客户端吗？这意味着客户端必须导入可能抛出的所有异常。用更少的细节抛出新的自定义异常会更好吗？因为客户端不需要知道出错的所有细节。你应该在客户端登录什么？我甚至听说过使用返回码（为了提高效率？）告诉来电者发生了什么事。

要记住的重要一点是，客户必须被告知出了什么问题。 “Something failed”或根本没有通知的通用答案是不可接受的。那么运行时（未经检查）异常呢？

Answer 1

似乎您希望能够区分故障是由于系统故障（例如服务或机器故障）还是业务逻辑故障（例如用户不存在）。

我建议使用您自己的自定义异常从RMI调用中包装所有系统异常。您仍然可以通过将其作为原因传递给自定义异常来维护异常中的信息（这在Java中是可能的，不确定其他语言）。这样客户端只需要知道如何处理系统故障原因中的一个异常。是否检查此自定义异常或运行时是否有争议（可能取决于您的项目标准）。我肯定会记录这种类型的失败。

业务类型失败可以表示为单独的异常或某种类型的默认（或null）响应对象。我会尝试从这种类型的故障中恢复（即采取一些替代操作）并仅在恢复失败时记录。

Answer 2

在过去的项目中，我们会在层的最顶层捕获所有服务层（层）异常，通过DTO / VO将特定于应用程序的错误代码/信息传递给UI。这是一种简单的方法，因为每个服务都在同一个地方发生了所有错误处理的既定模式，而不是分散在服务和UI层中。

然后所有UI要做的就是检查DTO / VO是否有标志（hasError？）并显示错误消息，它不必知道也不关心实际的异常是什么。

Answer 3

我总是会在我的应用程序中记录异常（在问题中定义的服务器端）。

然后我会抛出一个异常，被客户端抓住。如果调用者可以采取纠正措施来防止异常，那么我将确保该异常包含此信息（例如DateTime argName must not be in the past）。如果错误是由第三方系统的某些中断引起的，那么我可能会将此信息通过调用堆栈传递给调用者。

但是，如果异常主要是由我系统中的错误引起的，那么我将构建我的异常处理，以便使用非信息性异常消息（例如General failure）。

Answer 4

这就是我的所作所为。每个远程方法实现都捕获服务器端的所有异常并记录它们。然后它们被包装在自定义异常中，该异常将包含问题的描述。此描述必须对客户端有用，因此它不会包含捕获的Exception的所有详细信息，因为客户端不需要它们。它们已经在服务器端登录。现在，在客户端上，可以按用户的意愿处理这些异常。

为什么我选择使用Exceptions而不返回代码是因为返回码的一个非常重要的缺点：你不能不费力地将它们扔到更高的级别。这意味着您必须在通话后立即检查错误并在那里处理。但这可能不是我想要的。