.net - 什么是 System.ServiceModel.Diagnostics.CallbackException，为什么我不能处理它？

Question

在我的 WCF 客户端类中，我正在处理 Faulted()事件，以便如果远程服务抛出异常并使 channel 出错，我仍然至少可以正常关闭它。这是我的代码:

protected void RemoteDataRetriever_Faulted(object sender, EventArgs e)
{
    (sender as ICommunicationObject).Abort();
    this.Dispose();
    throw new ChannelTerminatedException("The remote service threw an unhandled exception and as a result the channel has been closed.");
}

所以我期望的是客户端可以处理 ChannelTerminatedException我手动抛出并向用户发送消息等。相反，我的异常被包裹在 System.ServiceModel.Diagnostics.CallbackException 中。 .好的。除了这里有一个问题:ServiceModel 库中不存在此 CallbackException 并且我似乎没有办法处理它，除非作为通用 Exception ，这对我的单元测试没有好处。这到底是怎么回事？我可以以某种方式禁用它并抛出我最初想要的异常吗？

Answer 1

事实证明，System.ServiceModel.Diagnostics.CallbackException是一个内部类，填充在一个鲜为人知的程序集中，称为“%SystemRoot%\Microsoft.net\Framework\v3.0\Windows Communication Foundation\SMDiagnostics.dll”，它本身只包含内部类。好吧，这很糟糕，因为这意味着我们永远无法捕获该异常。但是，我能够找到实例化上述异常的类/方法 (System.ServiceModel.Diagnostics.ExceptionUtility.ThrowHelperCallback(Exception innerException)) 并发现它被 CommunicationObject 中的虚方法 OnFaulted() 调用。因此理论上任何派生自 CommunicationObject 的类(抱歉 ClientBase<T>)都可以覆盖该方法并告诉它不要调用 ThrowHelperCallback()。这意味着唯一可行的候选者是派生自 ChannelFactoryBase<T> 的类。 .从理论上讲，我可以继续实现我自己的自定义 channel 工厂，它可以抑制烦人的 CallbackException，但目前工作量太大，所以我想我只需要处理它。

编辑:@Jeremy - 如果我检查通过线路返回的 SOAP 信封，我发现它给了我一个通用错误，正如预期的那样，这表明 CallbackException 没有被序列化，因此没有在服务器上生成。

<s:Body>
    <s:Fault>
        <s:Code>
            <s:Value>s:Receiver</s:Value>
            <s:Subcode>
                <s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
            </s:Subcode>
        </s:Code>
        <s:Reason>
            <s:Text xml:lang="en-US">The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the &lt;serviceDebug&gt; configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.</s:Text>
        </s:Reason>
    </s:Fault>
</s:Body>