最佳实践 - 从Web服务中抛出异常 [英] Best practices - throwing exceptions from a Web Service

问题描述

我们有我们用ajax（jQuery的）从我们的ASP.NET应用程序调用ASMX Web服务。

We have an ASMX web service which we invoke from our ASP.NET application using ajax (jQuery).

从我们的网站方法的典型的例子是这样的：

A typical example from our web methods would be something like:

[WebMethod]
public void DoSomething(BusinessObject myParameter)
{

    try
    {
       BL.DoSomethingWithParam(myParameter);
    }
    catch(Exception ex)
    { 
        //logic to log the actual exception goes here
        //and then we throw a more user-friendly error as so:
        throw new Exception("Unable to perform action such an such");
    }
}

在客户端我们有这样的事情：

On the client-side we would have something like this:

$.ajax({
   type: "POST",
   url: "WebService.asmx/DoSomething",
   data: "{}",
   contentType: "application/json; charset=utf-8",
   dataType: "json",
   success: function(result) {
      //do something with result.d
    },
   error: function(xhr, ajaxOptions, thrownError){ 
      alert($.parseJSON(xhr.Response.Text).Message);
   }
});

有几个问题与上面的方法，我想修复：

There are several problems with above approach, which I want to fix:

1. 当我们在本地测试我们的盒子我们的应用程序，Internet Explorer显示我们扔在我们的网站方法抛出新的异常线（在提供的例子code的情况下，实际的错误信息：无法执行操作如此这般）的但当我们部署到舞台环境和远程测试;它不再显示我们抛出错误，而是这样的：。已经有一个错误处理您的请求


2. 在火狐（我们没有测试更多的浏览器），它不会显示在所有，但Firebug的任何内容都会显示被抛出一个HTTP 500错误。

1. When we test our application locally on our boxes, Internet Explorer displays the actual error message we throw on the throw new Exception line on our web method (In the case of the example code provided: "Unable to perform action such and such") BUT when we deploy to the stage environment and test remotely; it no longer displays the error we throw, but rather this: "There has been an error processing your request."
2. On Firefox (we didn't test more browsers), it doesn't display anything at all but Firebug shows a HTTP 500 error being thrown.

总之，我们不能妥善处理这一点，所以我的问题是：

In conclusion we are not handling this appropriately, so my questions are:

1. 什么是这些错误传达给客户端，并有一致的行为在所有浏览器的最好方式，两者在本地和远程测试时？


2. 为什么不打破IE以同样的方式Firefox的呢？当然，测试远程IE排序休息过，由没有显示真正的错误消息，并替换它为通用已经有错误处理您的请求，但为什么不火狐照着做？


3. 如果考虑到这个Web服务也将被其他Java Web应用程序的公司内消费，什么是保持与这些应用程序的互操作性的最佳方式？我们怎么能扔还是在我们的网站的方法，这些异常和具有的Java应用程序能够赶上他们，并适当地处理它们？

1. What's the best way to communicate these errors to the client side and have consistent behavior amongst all browsers, both, when testing locally and remotely?
2. Why doesn't IE break the same way Firefox does? Granted, testing remotely IE sort of breaks too, by not showing the real error message and replacing it for the generic There has been an error processing your request but why doesn't Firefox do the same?
3. Considering the fact that this web service will also be consumed by other Java Web apps within the company, what's the best way to maintain interoperability with these apps? How can we still throw these exceptions on our web methods and have the Java app be able to catch them and handle them appropriately?

我们现在实施的 - 对于一个选择，我们仍然在开发相位时发生错误，但是这的确是一个丑陋的黑客/不雅的方式这样做只是为了回报从我们的网站方法的字符串。

One alternative we implemented -for now, we are still in development phase- is just to return a string from our web methods when an error occurs but this is really an ugly hack/inelegant way to do this.

注意：不要问我在哪里有一个错误处理您的请求消息来自何处。我没有最微弱的想法。我们没有在我们的code任何会返回该消息。

Note: Don't ask me where is the "There has been an error processing your request" message coming from. I don't have the faintest idea. We don't have anything in our code that would return that message.

推荐答案

我不知道这是正确的方式已尚未出现因该是如何被使用的Web服务的变化如此之快，最终的事实，构建任何客户端使用该服务能够处理无论您选择的方法。我毫不怀疑，最终人会设计，但现在就看你了。

I don't know that a "correct" way has yet emerged due to the fact that how web services are being utilized is changing so rapidly and, ultimately, any client being constructed to consume the service is capable of handling whatever method you choose. I have no doubt that ultimately one will be devised but for now it's up to you.

这就是说尽量避免一些我在过去看到的更常见的陷阱。

That being said try to avoid some of the more common pitfalls I've seen in the past.

1. 缺乏一致性：如果您的Web服务有多种方法设计出一种方式，他们都以同样的方式传达的错误，使您更方便的方法消耗。我个人preFER在协议栈的后尘，并使用某种一致的报头。与共同的报头建立你产生的消息，使得相同的逻辑可在整个客户code可用来确定是否该方法调用是成功的。


2. 不支持多错误信息：有时多个故障的发生。致盲客户端二级错误可能是一个滋扰，减缓调试尝试。


3. 缺乏鉴定为错误信息：如果错误是某一特定领域是无效的允许客户以编程方式确定哪些字段的结果是罪魁祸首根据您提供的信息
。

我一般先从这些天的方法看起来是这样的：

The approach I generally start with these days looks something like this:

{
    Success: bool,
    Errors[]: {
        Id: string,
        Source: string,
        Message: string
    },
    Message: { *Method specific structure* }
}

这篇关于最佳实践 - 从Web服务中抛出异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！