远程方法的例外情况的最佳做法是什么？远程方法的例外情况
我确定您需要处理远程方法实现级别的所有异常，因为您需要将其记录在服务器端。但之后你应该做什么？
如果你将异常封装在一个RemoteException（java）中并把它抛给客户端？这意味着客户端必须导入可能抛出的所有异常。用更少的细节抛出新的自定义异常会更好吗？因为客户不需要知道错误的全部细节。你应该登录客户端？我甚至听说过使用返回代码（为了提高效率？）来告诉调用者发生了什么事。
重要的是要记住，客户端必须被告知出了什么问题。 “一些失败”或根本没有通知的通用答案是不可接受的。那么运行时（未检查）异常呢？
这就是我所做的。每个远程方法实现都捕获服务器端的所有异常并记录它们。然后它们被封装在自定义异常中，其中将包含问题的描述。此说明必须对客户端有用，因此它不会包含捕获的异常的所有细节，因为客户端不需要它们。他们已经登录到服务器端。现在，在客户端上，这些异常可以按照用户的意愿来处理。
为什么我选择使用异常而不是返回代码是因为返回代码的一个非常重要的缺点：你不能在没有一些努力的情况下将它们扔到更高的层次。这意味着你必须在通话之后检查错误并在那里处理。但这可能不是我想要的。
在过去的项目中，我们会捕获层顶部的所有服务层（层）异常，并通过DTO的/ VO将应用程序特定的错误代码/信息传递给UI。这是一种简单的方法，因为在每个服务的同一个地方都有一个确定的错误处理模式，而不是散布在服务和UI层上。
然后所有的用户界面必须做的是检查DTO/VO的标志（hasError？）并显示错误信息，它不必知道也不在乎实际的异常。
您似乎希望能够区分故障是由于系统故障（例如服务或机器故障）还是业务逻辑故障（例如，用户不存在）造成的。
我建议使用您自己的自定义异常来包装来自RMI调用的所有系统异常。您仍然可以通过将异常中的信息传递给您的自定义异常（原因可能在Java中，不确定其他语言）来维护异常中的信息。这样，客户端只需要知道如何处理导致系统故障的一个例外。是否检查此自定义异常或运行时是否有争议（可能取决于您的项目标准）。我肯定会记录这种类型的失败。
业务类型失败可以表示为单独的异常或某种类型的默认（或空）响应对象。我会尝试从这种类型的故障中恢复（即采取一些替代措施），并且只有在恢复失败时才进行日志记录。
我总是在我的应用程序内（在您的问题中定义的服务器端）记录异常。
然后我会抛出一个异常，被客户端抓住。如果调用者可以采取纠正措施来防止异常，那么我会确保该例外包含此信息（例如DateTime argName must not be in the past）。如果错误是由第三方系统的某些中断引起的，那么我可能会将这些信息通过调用栈传递给调用者。
但是，如果这个异常实质上是由我系统中的一个错误引起的，那么我将构造我的异常处理，以便使用非信息异常消息（例如General failure）。