从.NET Web服务抛出异常

Question

我有一组使用[WebMethod]属性生成的Web服务。如果其参数未正确指定（且无法使用合理的默认值），从这样的方法中抛出ArgumentException是否被认为是“良好实践”？如果是，那么是否应该捕获并重新抛出此异常以便在服务器和客户端上记录日志？

- Chris Cooper

---

据我所知，应该不需要重新抛出异常，因为您可以配置故障以通过网络发送。而且，表面上看，我会说是的，抛出异常，但这取决于 - 您的框架可能被结构化为使用具有“结果”和“错误”集合的组合类型，例如。 - Grant Thomas

Answer 1

不，从 Web 服务中抛出异常并不是一个好的做法，因为 .NET 异常（例如 ArgumentException）不支持跨平台（考虑 Java 客户端需要如何响应）。

在 Web 服务中指示异常的标准机制是 SOAP Fault。

使用 .asmx，抛出 SOAPException 将为您生成一个故障。

如果您转移到 WCF，则可以查看 FaultContracts。

为了改善在 .Net 客户端和 .Net 服务器之间进行远程异常调试的情况，您可以使用 includeExceptionDetailInFaults 在配置中欺骗并通过网络发送异常。但是，此异常本身必须可序列化才能正常工作。但是，在系统达到生产状态之前，您需要将其关闭。

另外，您经常会发现，如果调用者的 SOAP 请求调用过于格式不良（例如，如果您的参数包括无法反序列化的实体），则根本不会调用您的 WebMethod - 调用者只会收到故障（通常相当晦涩）。

对于来自客户端调用您的服务的错误参数引发的上述故障应该在验证调用参数时生成。

可能相关 - 一旦请求通过验证，为了您自己的内部系统状态断言，您还可以使用代码合同来检测内部错误（或可能是缺少早期应该发生的验证）。但是，这些不会传播到客户端。

- StuartLC

Answer 2

使用异常和自定义错误代码总是一个难以决定的问题。您应该估计情况有多“特殊”，以及您计划如何在消费者端处理错误。通常在意外情况下（例如重要参数丢失）使用异常，而使用自定义错误代码来处理类似业务的错误。

更新：当然，这仅适用于创建新服务的情况。如果您修改现有服务，则必须知道现有客户端如何使用它以及他们期望的错误代码。

- Dercsár

Answer 3

这里有一篇关于Web服务异常的好文章。

- adrianm