WCF REST服务 - 通用异常处理 [英] WCF REST Services - Generic exception handling

问题描述

我有很多的遗留code，现在是一个后端的WCF REST服务 - 这曾经是一个通常的WCF服务后台之前，如果该事项。我想实现，将赶在任何方法的任何异常，并对其进行分析的机制。如果它原来是一个已知的错误，它会被处理，变成了一个友好的前瞻性故障。

I have a lot of legacy code that is now a backend for a WCF REST service - it used to be a usual WCF service backend before, if that matters. I want to implement a mechanism that would catch any exception in any method and analyze it. If it turns out to be a known error, it will be processed and turned into a friendly-looking fault.

我知道我可以抛出的FaultException 或 WebProtocolException ，而不是平常的例外，但也有很多在这里抛出异常遍布code，并寻找所有这些地方是一个相当痛苦的选择。

I know that I can throw FaultException or WebProtocolException instead of 'usual' exceptions, but there are lots of places where exceptions are thrown all over the code, and looking for all of them is quite a painful option.

我想补充的是创造它覆盖标准 WebHttpBehavior.AddServerErrorHandlers 方法，并增加了一个新的行为端点行为扩展我的错误处理程序（ IErrorHandler 实现）到终点调度错误处理程序的集合。里面的错误处理我分析了异常，并创建（或不创建）所需的故障在此基础上的异常。

I tried to add an endpoint behavior extension that creates a new behavior which overrides standard WebHttpBehavior.AddServerErrorHandlers method and adds my error handlers (IErrorHandler implementations) to the endpoint dispatcher error handlers collection. Inside the error handlers I analyze the exception and create (or do not create) a desired fault basing on this exception.

我希望这个机制返回的自定义数据的任何已知的例外，但是我错了。好老微软已经实现了一个奇妙的必然 WebHttpBehavior2 ，它无条件地增加了一个内部​​的 Microsoft.ServiceModel.Web.WebErrorHandler 进入端点调度错误处理程序收集的结束。该处理器将忽略所有previously执行的处理程序，并只承认一小部分例外的，而绝大多数是PTED为内部服务器错误，仅此而已跨$ P $。

I expected this mechanism to return custom data for any known exception, but I was wrong. Good old Microsoft has implemented a wonderful inevitable WebHttpBehavior2, which unconditionally adds an internal Microsoft.ServiceModel.Web.WebErrorHandler into the end of endpoint dispatcher error handlers collection. This handler ignores all previously executed handlers and recognizes only a small set of exceptions, while the majority is interpreted as "Internal Server Error", and nothing more.

现在的问题是我是否在正确的道路，有一个方法来禁用该处理程序在WCF REST机制，或用新的异常介绍它（例如，当任何异常被捕获，它首先由我处理程序处理如果他们抛出/回报率，例如，FaultException异常，那么这个新的异常被提供给 Microsoft.ServiceModel.Web.WebErrorHandler ，而不是原来的）。如果我所有的实验 IErrorHandler 和行为扩展是毫无价值的，有什么替代方案？同样，我真的不想修改异常抛出的逻辑，我想一个地方捕获异常并进行处理。

The question is whether I am on a right path and there is a way to disable this handler in WCF REST mechanism, or introduce it with a new Exception (e.g., when any exception is caught, it is first processed by my handlers and if they throw/return, for instance, FaultException, then this new exception is supplied to Microsoft.ServiceModel.Web.WebErrorHandler instead of the original one). If all my experiments with IErrorHandler and behavior extensions are worthless, what is an alternative? Again, I really do not want to modify the exception throwing logic, I want one place to catch the exceptions and process them.

非常感谢！

推荐答案

当你改变了WCF SOAP服务，REST，错误报告和处理改变整个心态。

When you change the WCF SOAP services to REST, the whole mindset of error reporting and handling changes.

在SOAP，缺点是你合同的组成部分。在REST，他们简直成了codeS您在HTTP响应code和描述输出。

In SOAP, faults are part of your contract. In REST, they simply become codes that you output in the HTTP response code and description.

下面是一个包罗万象片段：

Here is a catch snippet:

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
}

所以我建议你创建一个帮助code这会创建相关的错误codeS，放在了响应。

So I would suggest you create a helper code which creates relevant error codes for you and put in the response.

这篇关于WCF REST服务 - 通用异常处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！