远程方法异常的最佳实践是什么？
我确定您需要在远程方法实现级别处理所有异常，因为您需要在服务器端记录它。但是之后你应该怎么做？
您是否应该将异常包装在 RemoteException (java) 中并将其抛出给客户端？这意味着客户端必须导入所有可能抛出的异常。抛出一个细节更少的新自定义异常会更好吗？因为客户不需要知道问题的所有细节。你应该在客户端登录什么？我什至听说过使用返回码（也许是为了提高效率？）来告诉调用者发生了什么。
要记住的重要一点是，必须告知客户出了什么问题。“某事失败”或根本没有通知的通用答案是不可接受的。那么运行时（未经检查的）异常呢？
您似乎希望能够区分故障是由于系统故障（例如服务或机器停机）还是业务逻辑故障（例如用户不存在）造成的。
我建议使用您自己的自定义异常来包装 RMI 调用中的所有系统异常。您仍然可以通过将其作为原因传递给您的自定义异常来维护异常中的信息（这在 Java 中是可能的，不确定其他语言）。这样客户只需要知道如何处理导致系统故障的一个异常。是否检查此自定义异常或运行时有待讨论（可能取决于您的项目标准）。我肯定会记录这种类型的失败。
业务类型失败可以表示为单独的异常或某种类型的默认（或空）响应对象。我会尝试从这种类型的故障中恢复（即采取一些替代措施）并仅在恢复失败时记录。
在过去的项目中，我们会在最顶层捕获所有服务层（层）异常，通过 DTO/VO 将应用程序特定的错误代码/信息传递给 UI。这是一种简单的方法，因为每个服务的所有错误处理都发生在同一个地方，而不是分散在服务和 UI 层中。
然后 UI 所要做的就是检查 DTO/VO 的标志（hasError？）并显示错误消息，它不必知道也不关心实际的异常是什么。
我总是会在我的应用程序中记录异常（在您问题中定义的服务器端）。
然后我会抛出一个异常，被客户端捕获。如果调用者可以采取纠正措施来防止异常，那么我将确保异常包含此信息（例如DateTime argName must not be in the past）。如果错误是由第三方系统的某些中断引起的，那么我可能会将此信息通过调用堆栈传递给调用者。
然而，如果异常本质上是由我的系统中的错误引起的，那么我将构建我的异常处理，以便使用非信息性异常消息（例如General failure）。
这就是我所做的。每个远程方法实现都会捕获服务器端的所有异常并记录它们。然后将它们包装在自定义异常中，其中将包含问题的描述。这个描述必须对客户端有用，所以它不会包含捕获的异常的所有细节，因为客户端不需要它们。他们已经在服务器端登录。现在，在客户端，可以按照用户的意愿处理这些异常。
Why I chose using Exceptions and not return codes is because of one very important drawback of return codes: you can't throw them to higher levels without some effort. This means you have to check for an error right after the call and handle it there. But this may not be what I want.