【发布时间】：2010-09-10 16:11:07
【问题描述】：
我正在设计一个 WCF 服务，它将返回一个响应代码（例如 0 表示成功，或者另一个数字表示错误）。此外，Web 服务的所有方法都会执行几种常见的验证（例如验证 apiKey）。
我想知道是否有最佳实践方法或组织和检索这些响应代码和消息。
感谢您的任何建议。
【问题讨论】：
标签： web-services wcf
【发布时间】：2010-09-10 16:11:07
【问题描述】：
理想情况下，不要使用响应代码。成功时返回可用（或无效）的东西，失败时抛出异常。
人们处理异常。我们经常忘记查看返回的代码，尤其是在 99% 的情况下它是成功的，而且我们不关心任何响应。所以我们不捕获。然后我们就不用费心检查失败了。然后我们花了 2 天时间追踪一个我们找不到的错误，因为没有抛出异常，我们不知道使用您的 web 服务的 600,000 行应用程序失败的地方......我们甚至不知道这是对您的调用失败的网络服务。只是某些数据由于某些未知原因而出错。
有一个关于这个的话题：Which and Why do you prefer Exceptions or Return Codes
【讨论】：
-
乍得，这很有意义。但是，是否可以在不知道从哪个平台使用服务的情况下从 Web 服务抛出异常？我最初的想法是建立一个封装代码和消息的DataContract。这将如何被异常替换？
-
@XSaint32，不能说我已经做了很多，但我认为这不是问题。我很确定我有一个调用 Java 服务的 .NET 应用程序，它可以毫无问题地捕获异常。结果最终将被序列化为 xml/soap。据我所知，添加 Web 服务引用时生成的类会处理这个问题。
-
这种方法适用于 xml/soap 包装器，但我可能需要使用 REST 提供这些服务。 RESTful 服务是否能够抛出除 HTTP 异常之外的任何内容？我需要假设使用 Web 服务的客户端可能是一个简单的 PHP cURL 站点。
不要直接使用返回码。返回码通常表示成功、预期失败和意外失败。 Web 服务用预期的错误和意外的错误代替了这种机制。检查FaultContract 和FaultException<T> 以了解预期故障的实施细节。意外故障是任何其他异常。这是最佳做法。
【讨论】：