我们有几百个通过 ADO.NET 调用存储过程的 WCF 服务。我们希望客户端更智能地处理服务器异常。我有使用具有自定义故障类型的通用 FaultException 的工作代码，但我想只要我在这里，我想尝试抛出非通用 FaultException，并将所有额外信息放入其数据集合中。
但我无法做到这一点。FaultException 是按照我的意愿在服务器上创建的，我将其抛出，但有人捕捉到它并抛出一个新的 FaultException，其标准数据值是：“MethodName”、“parameters”、“AsyncActionDescription”。所以我要么做错了，要么你不能那样做。
我很难找到这方面的文档。一切都是关于使用泛型 FaultException<T>。仅出于这个原因，我想我会坚持使用泛型，特别是因为我已经让它工作了。因为 STRONGLY TYPED 无疑有人会正确地提醒我。
我只是好奇这里发生了什么。
通过没有找到答案，您在这里看到的是 WCF 强烈地强制分离有关服务故障的关注点。基本问题是“客户如何知道该怎么做？” 从客户的角度来看，它可以是 S_OK 或 !S_OK 来解释来自 COM 的 HRESULT。
不向客户提供特定故障背后的想法实际上是客户对问题的了解远少于服务。最重要的是，客户更不愿意了解如何弥补服务失败。异常有时是非常特定于技术的，这会在客户端和服务之间引入耦合形式。
您可以使用故障合约与客户端进行通信。FaultException<T>可以帮助将特定异常转换为故障。
我建议您阅读Juval 的 WCF 圣经书。第 6 章有很多关于故障的好信息。
还有 IncludeExceptionDetailsInFaults 服务行为。适合调试，但不要在生产中使用它。
[ServiceBehavior(IncludeExceptionDetailsInFaults = true)]
class MyService : IMyContract
{...}