我有很多遗留代码,现在是WCF REST服务的后端 - 如果这很重要,它之前曾经是一个常见的WCF服务后端.我想实现一种机制,可以捕获任何方法中的任何异常并进行分析.如果结果是已知错误,它将被处理并变成友好的故障.
我知道我可以抛出FaultException或者WebProtocolException代替"通常"的异常,但是有很多地方会在整个代码中抛出异常,并且查找所有这些异常是一个非常痛苦的选择.
我尝试添加一个端点行为扩展,它创建一个覆盖标准WebHttpBehavior.AddServerErrorHandlers方法的新行为,并将我的错误处理程序(IErrorHandler实现)添加到端点调度程序错误处理程序集合中.在错误处理程序内部,我分析异常并根据此异常创建(或不创建)所需的错误.
我希望这种机制能够为任何已知异常返回自定义数据,但我错了.好老的微软已经实现了一个不可避免的好处WebHttpBehavior2,它无条件地将一个内部添加Microsoft.ServiceModel.Web.WebErrorHandler到端点调度程序错误处理程序集合的末尾.此处理程序忽略所有先前执行的处理程序,并仅识别一小组异常,而大多数异常被解释为"内部服务器错误",仅此而已.
问题是我是否在正确的路径上并且有一种方法可以在WCF REST机制中禁用此处理程序,或者使用新的Exception引入它(例如,当捕获到任何异常时,它首先由我的处理程序处理,如果它们是抛出/返回,例如,FaultException,然后提供这个新的异常Microsoft.ServiceModel.Web.WebErrorHandler而不是原始异常).如果我所有的实验IErrorHandler和行为扩展都毫无价值,那还有什么选择呢?同样,我真的不想修改异常抛出逻辑,我想要一个地方来捕获异常并处理它们.
非常感谢!
当您将WCF SOAP服务更改为REST时,错误报告和处理的整体思维方式会发生变化.
在SOAP中,错误是合同的一部分.在REST中,它们只是成为您在HTTP响应代码和描述中输出的代码.
这是一个捕获片段:
catch (Exception e)
{
Trace.WriteLine(e.ToString());
OutgoingWebResponseContext response = WebOperationContext.Current.OutgoingResponse;
response.StatusCode = System.Net.HttpStatusCode.UnsupportedMediaType; // or anything you want
response.StatusDescription = e.Message;
return null; // I was returning a class
}
Run Code Online (Sandbox Code Playgroud)
所以我建议你创建一个帮助代码,为你创建相关的错误代码并放入响应.
| 归档时间: |
|
| 查看次数: |
5944 次 |
| 最近记录: |