第一个例子描述允许一个未处理异常从服务实现层抛出到服务宿主的影响。注意在图片10.1，返回给调用者的异常类型时FaultException.这是一个在WCF中使用的继承自Exception基类类型来与SOAP错误协议集成的类型。
默认情况下，到达服务宿主且没有继承子FaultException的异常都被认为是一个潜在致命错误发送的条件。异常被一个FaultException取代同时原始异常信息被忽略除非开启IncludeExceptionDetialInFaults选项。FaultException接下来被当作一个SOAP错误进行序列化并返回给调用方(为单向操作请求保存。)再次，如果调用方是一个会话的一部分，那么会话将会被破坏而且将需要被重建。
由未处理异常创建的致命错误条件可以在它们到达服务宿主并抛出一个FaultException之前手动捕获来阻止。FaultException类有很多构造函数和属性允许你确定不同的涉及SOAP错误实现的需要和可选值，
建议的模式是服务的代码来捕获任何异常，并提取列入有关细节包含在一个新的FaultException实例中。这在列表10.6的例子中描述。
列表10.6 捕获一个异常并抛出一个FaultException
使用FaultCode 和 FaultReason 来扩展FaultException
列表10.5 是一个好的开始，但是它没有确定可以对客户端有用的额外信息。FaultException构造函数也支持FaultReason和FaultCode参数，用来对应地确定SOAP错误的原因和代码元素。
FaultCode有三个主要选项。一个发送方代码意味着调用方发送的消息有问题。如果什么也没有提供给FaultException那么这是默认选项。一个接收方代码意味着由于服务实现遇到了一个问题所以处理不能完成。相对的，可以提供自定义代码。
FaultReason类可以为应用程序本地化创建多个基于本地翻译特征的原因消息。SOAP 1.2 标准提供多个原因节点，每个都有一个localeID(例如，en-us用于美国英语)。 FaultReason 类接收一个FalutReasonText实例集合，它们自身包含有本地标识符的字符串翻译。
在列表10.7中，我们重新回到列表10.6中的示例代码并使用FaultCode 和 FaultReason 类来增加我们要序列化然后发送给调用方的错误信息。
列表10.7 使用FaultCode和FaultReason来扩展FaultException
因为ArgumentException 意味着提供给服务操作的值有一个问题，我们没有确定一个FaultCode, 所以将使用默认的发送者身份。对InvoiceNotFoundException,我们想要提示有一个服务相关的问题，所以使用静态方法CreateReceiverFaultCode() 来创建一个接收方代码。
在catch-call 部分，我们描述了使用其他FaultReason构造函数来向调用方提供传输错误消息。首先，会创建一个通用的FaultReasonText 入口列表，提供翻译和关联文化代码。然后构造FaultException,以及FaultReason构造函数的翻译列表。
为了在客户端访问翻译内容，FaultException类暴露一个定义GetMatchTranslation()方法的Reason属性。不加参数调用<exception>.Reason.GetMatchingTranslation() 来自动为当前线程所在文化区域接收翻译内容，或者提供一个特殊的CultureInfo 作为一个参数来接收一个特殊的翻译内容。
基本FaultExceptions 的限制
使用基本FaultException 类是一个简单的阻止未处理异常到达服务宿主并潜在地取消你的会话和客户端代理认证的方式。然而，FaultExceptions要承受缺少标识符的问题。如果你的服务仅返回FaultExceptions,你正在让客户端应用的开发人员创建鲁棒性异常处理机制变得困难。考虑列表10.8 的例子。
列表10.8 处理非类型化FaultExceptions
这里的挑战是没有FaultException的子类可以用来为一系列场景特别创建错误处理捕获区域。对客户端应用开发人员来说下一个可以使用的最好的方法是写代码来运行时检查每个异常并从属性中截取信息来期望可以确认恢复或者处理的正确原因。