想象一下，有一些管理员类与远程服务进行通信，例如，可以创建新的用户微服务并更新现有的用户配置文件。此管理器类在代码中的任何位置使用：在控制器和其他类中。在与远程服务交谈之前，我们的经理班并不知道提交的DTO是否有效。问题是：如果远程服务返回验证错误，下一步该怎么做？如何处理这个错误？我已经考虑过了，并有一些选择：
也许存在其他更好的解决方案？
P.S。假设远程服务以JSON格式返回错误，如果它是JSON-RPC，SOAP或REST微服务则无关紧要。
答案 0 :(得分：1)
除非您想将服务错误转换为不同的东西，或者甚至处理它们以在客户端层中做出某些决定，否则通常会以人类可读的方式格式化服务错误以在UI中显示以让用户知道什么出了问题。
另一方面，如果没有用户界面，则应该有记录器。就像在UI层中所做的那样，您可以格式化这些错误，将它们记录到文件或任何其他存储方法。
此外，您可能想了解有关fail-fast concept：
的更多信息在系统设计中，快速失效的系统是立即报告的系统 在其接口处任何可能表示失败的情况。 快速失效系统通常设计为停止正常操作 而不是试图继续一个可能有缺陷的过程。经常这样的设计 在操作的几个点检查系统的状态，所以任何 可以及早发现故障。一个故障快速模块通过了 负责处理错误，但没有检测到它们 系统的次高级别。
如果从微服务返回验证错误，那么经理是什么 上课应该呢？抛出异常或将这些错误放入某些错误中 在它的课堂上？
关于这个问题，我得出了一些结论，并且整个流程应该通过我称之为accumulated result (check the full description)的专门DTO：
表示传输两者的多用途正交实体 调用操作的结果以及有用的信息 呼叫者喜欢状态，状态描述和有关实际的详细信息 整个行动的结果。
这样，即使在多层体系结构中，每个层/层也可以向累积结果添加更多信息或做出决策。
可能有些人可能会争辩说你应该抛出异常，但我发现破坏的规则只是一个例外，而是一个预期的用例。
答案 1 :(得分：0)
如何处理来自远程服务的验证错误？
返回相关的HTTP status code，以及响应正文中必要的信息（有时无）。
如果它是SOAP或RESTful并不重要，想象一下JSON 回复
它的服务类型将决定您的故障处理方法。对于SOAP服务，您应该返回SOAP fault。