blocks|key|3122426|text|使用HTTP+status+code可能是一种RESTful方式，但这会建议您使用资源URI等使接口的其余部分成为RESTful。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3122427|实际上，您可以根据自己的喜好定义接口(例如，返回一个error对象，详细说明带有错误的属性，以及解释它的HTML块，等等)，但是一旦您决定了在原型中工作的内容，就必须保持一致。|3122428|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Using HTTP status codes would be a RESTful way to do it, but that would suggest you make the rest of the interface RESTful using resource URIs and so on. 

In truth, define the interface as you like (return an error object, for example, detailing the property with the error, and a chunk of HTML that explains it, etc), but once you've decided on something that works in a prototype, be ruthlessly consistent.

blocks|key|344853|text|我认为如果你只是冒泡一个异常，它应该在jQuery+callback+that+is+passed+in+for+the+'error'+option中处理。(我们还在服务器端将此异常记录到中央日志中)。不需要特殊的HTTP错误代码，但我很好奇其他人也会这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|344854|这就是我要做的，但那只是我的$.02|344855|如果您打算使用RESTful并返回错误代码，请尝试使用由W3C：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html设置的标准代码|344856|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.jquery.com/Ajax|1|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html^0|J|1K|0|0|0|W|1I|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

I think if you just bubble an exception, it should be handled in the <a href="http://docs.jquery.com/Ajax" rel="nofollow noreferrer">jQuery callback that is passed in for the 'error' option</a>. (We also log this exception on the server side to a central log). No special HTTP error code required, but I'm curious to see what other folks do, too.

This is what I do, but that's just my $.02 

If you are going to be RESTful and return error codes, try to stick to the standard codes set forth by the W3C: <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="nofollow noreferrer">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a>

blocks|key|3335406|text|我认为您不应该返回任何http错误代码，而应该返回对应用程序的客户端有用的自定义异常，以便接口知道实际发生了什么。我不会试图用404错误代码或类似的东西来掩盖真正的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3335407|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't think you should be returning any http error codes, rather custom exceptions that are useful to the client end of the application so the interface knows what had actually occurred. I wouldn't try and mask real issues with 404 error codes or something to that nature.

blocks|key|344872|text|您返回的HTTP状态代码应取决于发生的错误类型。如果数据库中不存在ID，则返回404；如果用户没有足够的权限进行Ajax调用，则返回403；如果数据库在能够找到记录之前超时，则返回500+(服务器错误)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|344873|jQuery会自动检测这样的错误代码，并运行您在Ajax调用中定义的回调函数。文档：http://api.jquery.com/jQuery.ajax/|offset|length|344874|$.ajax错误回调的简短示例：|style|CODE|344875|$.ajax({
++type:+'POST',
++url:+'/some/resource',
++success:+function(data,+textStatus)+{
++++//+Handle+success
++},
++error:+function(xhr,+textStatus,+errorThrown)+{
++++//+Handle+error
++}
});|code-block|syntax|javascript|344876|entityMap|0|LINK|mutability|MUTABLE|url|http://api.jquery.com/jQuery.ajax/^0|0|16|Y|0|0|0|6|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|G|5|6|7|11|8|@$D|12|E|13|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|14|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

The HTTP status code you return should depend on the type of error that has occurred. If an ID doesn't exist in the database, return a 404; if a user doesn't have enough privileges to make that Ajax call, return a 403; if the database times out before being able to find the record, return a 500 (server error).

jQuery automatically detects such error codes, and runs the callback function that you define in your Ajax call. Documentation: <a href="http://api.jquery.com/jQuery.ajax/" rel="noreferrer">http://api.jquery.com/jQuery.ajax/</a>

Short example of a <code>$.ajax</code> error callback:

<pre><code>$.ajax({
 type: 'POST',
 url: '/some/resource',
 success: function(data, textStatus) {
 // Handle success
 },
 error: function(xhr, textStatus, errorThrown) {
 // Handle error
 }
});
</code></pre>

blocks|key|3335456|text|有关您的情况的最佳实践的一些见解，请参阅this+question。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3335457|主要的建议(来自上述链接)是标准化处理程序查找的响应结构(无论是成功还是失败)，捕获服务器层的所有异常并将它们转换为相同的结构。例如(来自this+answer)：|3335458|{
++++success:false,
++++general_message:"You+have+reached+your+max+number+of+Foos+for+the+day",
++++errors:+{
++++++++last_name:"This+field+is+required",
++++++++mrn:"Either+SSN+or+MRN+must+be+entered",
++++++++zipcode:"996852+is+not+in+Bernalillo+county.+Only+Bernalillo+residents+are+eligible"
++++}
}+|code-block|syntax|javascript|3335459|这是stackoverflow使用的方法(如果你想知道别人是如何做这类事情的)；像投票这样的写操作有"Success"和"Message"字段，无论投票是否被允许：|style|CODE|3335460|{+Success:true,+NewScore:1,+Message:"",+LastVoteTypeId:3+}|3335461|作为@Phil.H+pointed+out，无论你选择什么，你都应该保持一致。这说起来容易做起来难(开发中的一切都是如此！)。|3335462|例如，如果您在SO上提交评论太快，而不是一致并返回|3335463|{+Success:+false,+Message:+"Can+only+comment+once+every+blah..."+}|3335464|因此将抛出一个服务器异常(HTTP+500)，并在其error回调中捕获它。|3335465|尽管使用jQuery+%2B+.ashx+%2B+HTTP状态码“感觉正确”，但它会增加客户端代码库的复杂性，而不是它的价值。要知道，jQuery并不“检测”错误代码，而是缺少成功代码。在尝试使用jQuery围绕http响应代码设计客户端时，这是一个重要的区别。您只有两个选择(是“成功”还是“错误”？)，您必须自己进一步分支。如果你有少量的WebServices驱动少量的页面，那么这可能是可以的，但是更大的规模可能会变得混乱。|3335466|在HTTP中，返回一个自定义对象要比自定义WebService状态码自然得多。另外，您还可以免费获得JSON序列化。|3335467|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/574035/how-to-handle-db-constraint-violations-in-the-user-interface|1|https://stackoverflow.com/questions/574035/how-to-handle-db-constraint-violations-in-the-user-interface/575092#575092|2|https://stackoverflow.com/questions/674027/what-should-a-json-service-return-on-failure-error#674046^0|K|D|0|0|1X|B|1|0|0|1E|9|1O|9|0|0|2|J|2|0|0|0|D|8|Q|5|0|D|5|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@$A|1J|B|1K|1|1L]]|C|$]]|$1|F|3|G|5|H|7|1M|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1N|8|@$A|1O|B|1P|M|N]|$A|1Q|B|1R|M|N]]|9|@]|C|$]]|$1|O|3|P|5|H|7|1S|8|@]|9|@]|C|$I|J]]|$1|Q|3|R|5|6|7|1T|8|@]|9|@$A|1U|B|1V|1|1W]]|C|$]]|$1|S|3|T|5|6|7|1X|8|@]|9|@]|C|$]]|$1|U|3|V|5|H|7|1Y|8|@]|9|@]|C|$I|J]]|$1|W|3|X|5|6|7|1Z|8|@$A|20|B|21|M|N]|$A|22|B|23|M|N]]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|24|8|@$A|25|B|26|M|N]]|9|@]|C|$]]|$1|10|3|11|5|6|7|27|8|@]|9|@]|C|$]]|$1|12|3|-4|5|6|7|28|8|@]|9|@]|C|$]]]|13|$14|$5|15|16|17|C|$18|19]]|1A|$5|15|16|17|C|$18|1B]]|1C|$5|15|16|17|C|$18|1D]]]]

See <a href="https://stackoverflow.com/questions/574035/how-to-handle-db-constraint-violations-in-the-user-interface">this question</a> for some insight into best-practices for your situation.

The topline suggestion (from said link) is to standardize a response structure (for both success and failure) that your handler looks for, catching all Exceptions at the server layer and converting them to the same structure. For example (from <a href="https://stackoverflow.com/questions/574035/how-to-handle-db-constraint-violations-in-the-user-interface/575092#575092">this answer</a>):

<pre><code>{
 success:false,
 general_message:"You have reached your max number of Foos for the day",
 errors: {
 last_name:"This field is required",
 mrn:"Either SSN or MRN must be entered",
 zipcode:"996852 is not in Bernalillo county. Only Bernalillo residents are eligible"
 }
} 
</code></pre>

This is the approach stackoverflow uses (in case you were wondering how others do this kind of thing); write operations like voting have <code>"Success"</code> and <code>"Message"</code> fields, regardless of if the vote was allowed or not:

<pre><code>{ Success:true, NewScore:1, Message:"", LastVoteTypeId:3 }
</code></pre>

As <a href="https://stackoverflow.com/questions/674027/what-should-a-json-service-return-on-failure-error#674046">@Phil.H pointed out</a>, you should be consistent in whatever you choose. This is easier said than done (as is everything in development!). 

For example, if you submit comments too quickly on SO, instead of being consistent and returning

<pre><code>{ Success: false, Message: "Can only comment once every blah..." }
</code></pre>

SO will throw a server exception (<code>HTTP 500</code>) and catch it in their <code>error</code> callback.

As much as it "feels right" to use jQuery + <code>.ashx</code> + HTTP [status codes] IMO it will add more complexity to your client-side code base than it's worth. Realize that jQuery does not "detect" error codes but rather the lack of a success code. This is an important distinction when trying to design a client around http response codes with jQuery. You only get two choices (was it a "success" or "error"?), which you have to branch further on your own. If you have a small number of WebServices driving a small number of pages then it might be okay, but anything larger scale may get messy.

It's much more natural in a <code>.asmx</code> WebService (or WCF for that matter) to return a custom object than to customize the HTTP status code. Plus you get the JSON serialization for free.

blocks|key|346283|text|我肯定会返回一个500错误，其中包含一个描述错误条件的JSON对象，类似于how+an+ASP.NET+AJAX+"ScriptService"+error+returns。我相信这是相当标准的。在处理潜在意想不到的错误情况时保持一致性无疑是很好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|346284|另外，如果你是用C#编写的，为什么不直接使用.NET的内置功能呢？WCF和ASMX服务可以轻松地将数据序列化为JSON，而无需重新发明轮子。|346285|entityMap|0|LINK|mutability|MUTABLE|url|http://encosia.com/2009/03/04/use-jquery-to-catch-and-display-aspnet-ajax-service-errors/^0|11|1D|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I would definitely return a 500 error with a JSON object describing the error condition, similar to <a href="http://encosia.com/2009/03/04/use-jquery-to-catch-and-display-aspnet-ajax-service-errors/" rel="nofollow noreferrer">how an ASP.NET AJAX "ScriptService" error returns</a>. I believe this is fairly standard. It's definitely nice to have that consistency when handling potentially unexpected error conditions.

Aside, why not just use the built in functionality in .NET, if you're writing it in C#? WCF and ASMX services make it easy to serialize data as JSON, without reinventing the wheel.

blocks|key|347198|text|如果用户提供了无效的数据，那么它一定是一个400+Bad+Request+(请求包含错误的语法或无法满足)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|347199|entityMap^0|L|F|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

If the user supplies invalid data, it should definitely be a <code>400 Bad Request</code> (The request contains bad syntax or cannot be fulfilled.)

blocks|key|3122621|text|Rails框架使用422+Unprocessable+Entity来处理这些类型的错误。有关详细信息，请参阅RFC+4918。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3122622|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc4918#section-11.2^0|9|O|1I|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

Rails scaffolds use <code>422 Unprocessable Entity</code> for these kinds of errors. See <a href="https://www.rfc-editor.org/rfc/rfc4918#section-11.2" rel="nofollow noreferrer">RFC 4918</a> for more information.

blocks|key|349881|text|我花了几个小时来解决这个问题。我的解决方案基于以下愿望/要求：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|349882|在所有的JSON控制器actions.|349883|Preserve+(|unordered-list-item|349884|)状态码中都没有重复的样板错误处理代码。为什么？因为较高级别的关注点不应该影响较低级别的implementation.|349885|Be，所以当服务器上发生错误/异常时，能够获得JSON数据。为什么？因为我可能需要丰富的错误信息。例如错误消息、特定于域的错误状态代码、堆栈跟踪(在使用客户端的调试/开发environment).|349886|Ease中-最好使用jQuery。|349887|349888|349889|我创建了一个HandleErrorAttribute+(有关细节的解释，请参阅代码注释)。包括"usings“在内的一些细节被省略了，因此代码可能无法编译。在Global.asax.cs中的应用程序初始化期间，我将过滤器添加到全局过滤器，如下所示：|349890|GlobalFilters.Filters.Add(new+UnikHandleErrorAttribute());|code-block|syntax|javascript|349891|属性：|349892|namespace+Foo
{
++using+System;
++using+System.Diagnostics;
++using+System.Linq;
++using+System.Net;
++using+System.Reflection;
++using+System.Web;
++using+System.Web.Mvc;

++///+<summary>
++///+Generel+error+handler+attribute+for+Foo+MVC+solutions.
++///+It+handles+uncaught+exceptions+from+controller+actions.
++///+It+outputs+trace+information.
++///+If+custom+errors+are+enabled+then+the+following+is+performed:
++///+<ul>
++///+++<li>If+the+controller+action+return+type+is+<see+cref="JsonResult"/>+then+a+<see+cref="JsonResult"/>+object+with+a+<c>message</c>+property+is+returned.
++///+++++++If+the+exception+is+of+type+<see+cref="MySpecialExceptionWithUserMessage"/>+it's+message+will+be+used+as+the+<see+cref="JsonResult"/>+<c>message</c>+property+value.
++///+++++++Otherwise+a+localized+resource+text+will+be+used.</li>
++///+</ul>
++///+Otherwise+the+exception+will+pass+through+unhandled.
++///+</summary>
++[AttributeUsage(AttributeTargets.Class+%7C+AttributeTargets.Method)]
++public+sealed+class+FooHandleErrorAttribute+:+HandleErrorAttribute
++{
++++private+readonly+TraceSource+_TraceSource;

++++///+<summary>
++++///+<paramref+name="traceSource"/>+must+not+be+null.
++++///+</summary>
++++///+<param+name="traceSource"></param>
++++public+FooHandleErrorAttribute(TraceSource+traceSource)
++++{
++++++if+(traceSource+==+null)
++++++++throw+new+ArgumentNullException(@"traceSource");
++++++_TraceSource+=+traceSource;
++++}

++++public+TraceSource+TraceSource
++++{
++++++get
++++++{
++++++++return+_TraceSource;
++++++}
++++}

++++///+<summary>
++++///+Ctor.
++++///+</summary>
++++public+FooHandleErrorAttribute()
++++{
++++++var+className+=+typeof(FooHandleErrorAttribute).FullName+??+typeof(FooHandleErrorAttribute).Name;
++++++_TraceSource+=+new+TraceSource(className);
++++}

++++public+override+void+OnException(ExceptionContext+filterContext)
++++{
++++++var+actionMethodInfo+=+GetControllerAction(filterContext.Exception);
++++++//+It's+probably+an+error+if+we+cannot+find+a+controller+action.+But,+hey,+what+should+we+do+about+it+here?
++++++if(actionMethodInfo+==+null)+return;

++++++var+controllerName+=+filterContext.Controller.GetType().FullName;+//+filterContext.RouteData.Values[@"controller"];
++++++var+actionName+=+actionMethodInfo.Name;+//+filterContext.RouteData.Values[@"action"];

++++++//+Log+the+exception+to+the+trace+source
++++++var+traceMessage+=+string.Format(@"Unhandled+exception+from+{0}.{1}+handled+in+{2}.+Exception:+{3}",+controllerName,+actionName,+typeof(FooHandleErrorAttribute).FullName,+filterContext.Exception);
++++++_TraceSource.TraceEvent(TraceEventType.Error,+TraceEventId.UnhandledException,+traceMessage);

++++++//+Don't+modify+result+if+custom+errors+not+enabled
++++++//if+(!filterContext.HttpContext.IsCustomErrorEnabled)
++++++//++return;

++++++//+We+only+handle+actions+with+return+type+of+JsonResult+-+I+don't+use+AjaxRequestExtensions.IsAjaxRequest()+because+ajax+requests+does+NOT+imply+JSON+result.
++++++//+(The+downside+is+that+you+cannot+just+specify+the+return+type+as+ActionResult+-+however+I+don't+consider+this+a+bad+thing)
++++++if+(actionMethodInfo.ReturnType+!=+typeof(JsonResult))+return;

++++++//+Handle+JsonResult+action+exception+by+creating+a+useful+JSON+object+which+can+be+used+client+side
++++++//+Only+provide+error+message+if+we+have+an+MySpecialExceptionWithUserMessage.
++++++var+jsonMessage+=+FooHandleErrorAttributeResources.Error_Occured;
++++++if+(filterContext.Exception+is+MySpecialExceptionWithUserMessage)+jsonMessage+=+filterContext.Exception.Message;
++++++filterContext.Result+=+new+JsonResult
++++++++{
++++++++++Data+=+new
++++++++++++{
++++++++++++++message+=+jsonMessage,
++++++++++++++//+Only+include+stacktrace+information+in+development+environment
++++++++++++++stacktrace+=+MyEnvironmentHelper.IsDebugging+?+filterContext.Exception.StackTrace+:+null
++++++++++++},
++++++++++//+Allow+JSON+get+requests+because+we+are+already+using+this+approach.+However,+we+should+consider+avoiding+this+habit.
++++++++++JsonRequestBehavior+=+JsonRequestBehavior.AllowGet
++++++++};

++++++//+Exception+is+now+(being)+handled+-+set+the+HTTP+error+status+code+and+prevent+caching!+Otherwise+you'll+get+an+HTTP+200+status+code+and+running+the+risc+of+the+browser+caching+the+result.
++++++filterContext.ExceptionHandled+=+true;
++++++filterContext.HttpContext.Response.StatusCode+=+(int)HttpStatusCode.InternalServerError;+//+Consider+using+more+error+status+codes+depending+on+the+type+of+exception
++++++filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);

++++++//+Call+the+overrided+method
++++++base.OnException(filterContext);
++++}

++++///+<summary>
++++///+Does+anybody+know+a+better+way+to+obtain+the+controller+action+method+info?
++++///+See+http://stackoverflow.com/questions/2770303/how-to-find-in-which-controller-action-an-error-occurred.
++++///+</summary>
++++///+<param+name="exception"></param>
++++///+<returns></returns>
++++private+static+MethodInfo+GetControllerAction(Exception+exception)
++++{
++++++var+stackTrace+=+new+StackTrace(exception);
++++++var+frames+=+stackTrace.GetFrames();
++++++if(frames+==+null)+return+null;
++++++var+frame+=+frames.FirstOrDefault(f+=>+typeof(IController).IsAssignableFrom(f.GetMethod().DeclaringType));
++++++if+(frame+==+null)+return+null;
++++++var+actionMethod+=+frame.GetMethod();
++++++return+actionMethod+as+MethodInfo;
++++}
++}
}|349893|我已经开发了以下jQuery插件，以方便客户端使用：|349894|(function+($,+undefined)+{
++"using+strict";

++$.FooGetJSON+=+function+(url,+data,+success,+error)+{
++++///+<summary>
++++///+**********************************************************
++++///+*+UNIK+GET+JSON+JQUERY+PLUGIN.+++++++++++++++++++++++++++*
++++///+**********************************************************
++++///+This+plugin+is+a+wrapper+for+jQuery.getJSON.
++++///+The+reason+is+that+jQuery.getJSON+success+handler+doesn't+provides+access+to+the+JSON+object+returned+from+the+url
++++///+when+a+HTTP+status+code+different+from+200+is+encountered.+However,+please+note+that+whether+there+is+JSON
++++///+data+or+not+depends+on+the+requested+service.+if+there+is+no+JSON+data+(i.e.+response.responseText+cannot+be
++++///+parsed+as+JSON)+then+the+data+parameter+will+be+undefined.
++++///
++++///+This+plugin+solves+this+problem+by+providing+a+new+error+handler+signature+which+includes+a+data+parameter.
++++///+Usage+of+the+plugin+is+much+equal+to+using+the+jQuery.getJSON+method.+Handlers+can+be+added+etc.+However,
++++///+the+only+way+to+obtain+an+error+handler+with+the+signature+specified+below+with+a+JSON+data+parameter+is
++++///+to+call+the+plugin+with+the+error+handler+parameter+directly+specified+in+the+call+to+the+plugin.
++++///
++++///+success:+function(data,+textStatus,+jqXHR)
++++///+error:+function(data,+jqXHR,+textStatus,+errorThrown)
++++///
++++///+Example+usage:
++++///
++++///+++$.FooGetJSON('/foo',+{+id:+42+},+function(data)+{+alert('Name+:'+%2B+data.name);+},+function(data)+{+alert('Error:+'+%2B+data.message);+});
++++///+</summary>

++++//+Call+the+ordinary+jQuery+method
++++var+jqxhr+=+$.getJSON(url,+data,+success);

++++//+Do+the+error+handler+wrapping+stuff+to+provide+an+error+handler+with+a+JSON+object+-+if+the+response+contains+JSON+object+data
++++if+(typeof+error+!==+"undefined")+{
++++++jqxhr.error(function(response,+textStatus,+errorThrown)+{
++++++++try+{
++++++++++var+json+=+$.parseJSON(response.responseText);
++++++++++error(json,+response,+textStatus,+errorThrown);
++++++++}+catch(e)+{
++++++++++error(undefined,+response,+textStatus,+errorThrown);
++++++++}
++++++});
++++}

++++//+Return+the+jQueryXmlHttpResponse+object
++++return+jqxhr;
++};
})(jQuery);|349895|我能从这一切中得到什么？最终的结果是|349896|349897|我的控制器操作都没有对HandleErrorAttributes.|349898|None的要求，我的控制器操作包含任何重复的模板错误处理代码。|349899|我有一个单一的错误处理代码点，允许我轻松地更改日志记录和其他错误处理相关内容。|349900|一个简单的要求:返回JsonResult的控制器操作必须具有返回类型JsonResult，而不是像ActionResult这样的基类型。原因:查看FooHandleErrorAttribute.|349901|中的代码注释|349902|客户端示例：|349903|var+success+=+function(data)+{
++alert(data.myjsonobject.foo);
};
var+onError+=+function(data)+{
++var+message+=+"Error";
++if(typeof+data+!==+"undefined")
++++message+%2B=+":+"+%2B+data.message;
++alert(message);
};
$.FooGetJSON(url,+params,+onSuccess,+onError);|349904|欢迎您的评论！也许有一天我会在博客上介绍这个解决方案……|349905|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|1R|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1S|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1W|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1X|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1Z|8|@]|9|@]|A|$T|U]]|$1|Z|3|10|5|6|7|20|8|@]|9|@]|A|$]]|$1|11|3|12|5|S|7|21|8|@]|9|@]|A|$T|U]]|$1|13|3|14|5|6|7|22|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|16|3|17|5|F|7|24|8|@]|9|@]|A|$]]|$1|18|3|19|5|F|7|25|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|F|7|26|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|F|7|27|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|28|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|29|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|S|7|2A|8|@]|9|@]|A|$T|U]]|$1|1K|3|1L|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1M|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]]|1N|$]]

I've spend some hours solving this problem. My solution is based on the following wishes/requirements:

<ul>
<li>Don't have repetitive boilerplate error handling code in all JSON controller actions.</li>
<li>Preserve HTTP (error) status codes. Why? Because higher level concerns should not affect lower level implementation.</li>
<li>Be able to get JSON data when an error/exception occur on the server. Why? Because I might want rich error information. E.g. error message, domain specific error status code, stack trace (in debug/development environment).</li>
<li>Ease of use client side - preferable using jQuery.</li>
</ul>

I create a HandleErrorAttribute (see code comments for explanation of the details). A few details including "usings" has been left out, so the code might not compile. I add the filter to the global filters during application initialization in Global.asax.cs like this:

<pre><code>GlobalFilters.Filters.Add(new UnikHandleErrorAttribute());
</code></pre>

Attribute:

<pre><code>namespace Foo
{
 using System;
 using System.Diagnostics;
 using System.Linq;
 using System.Net;
 using System.Reflection;
 using System.Web;
 using System.Web.Mvc;

 /// &lt;summary&gt;
 /// Generel error handler attribute for Foo MVC solutions.
 /// It handles uncaught exceptions from controller actions.
 /// It outputs trace information.
 /// If custom errors are enabled then the following is performed:
 /// &lt;ul&gt;
 /// &lt;li&gt;If the controller action return type is &lt;see cref="JsonResult"/&gt; then a &lt;see cref="JsonResult"/&gt; object with a &lt;c&gt;message&lt;/c&gt; property is returned.
 /// If the exception is of type &lt;see cref="MySpecialExceptionWithUserMessage"/&gt; it's message will be used as the &lt;see cref="JsonResult"/&gt; &lt;c&gt;message&lt;/c&gt; property value.
 /// Otherwise a localized resource text will be used.&lt;/li&gt;
 /// &lt;/ul&gt;
 /// Otherwise the exception will pass through unhandled.
 /// &lt;/summary&gt;
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
 public sealed class FooHandleErrorAttribute : HandleErrorAttribute
 {
 private readonly TraceSource _TraceSource;

 /// &lt;summary&gt;
 /// &lt;paramref name="traceSource"/&gt; must not be null.
 /// &lt;/summary&gt;
 /// &lt;param name="traceSource"&gt;&lt;/param&gt;
 public FooHandleErrorAttribute(TraceSource traceSource)
 {
 if (traceSource == null)
 throw new ArgumentNullException(@"traceSource");
 _TraceSource = traceSource;
 }

 public TraceSource TraceSource
 {
 get
 {
 return _TraceSource;
 }
 }

 /// &lt;summary&gt;
 /// Ctor.
 /// &lt;/summary&gt;
 public FooHandleErrorAttribute()
 {
 var className = typeof(FooHandleErrorAttribute).FullName ?? typeof(FooHandleErrorAttribute).Name;
 _TraceSource = new TraceSource(className);
 }

 public override void OnException(ExceptionContext filterContext)
 {
 var actionMethodInfo = GetControllerAction(filterContext.Exception);
 // It's probably an error if we cannot find a controller action. But, hey, what should we do about it here?
 if(actionMethodInfo == null) return;

 var controllerName = filterContext.Controller.GetType().FullName; // filterContext.RouteData.Values[@"controller"];
 var actionName = actionMethodInfo.Name; // filterContext.RouteData.Values[@"action"];

 // Log the exception to the trace source
 var traceMessage = string.Format(@"Unhandled exception from {0}.{1} handled in {2}. Exception: {3}", controllerName, actionName, typeof(FooHandleErrorAttribute).FullName, filterContext.Exception);
 _TraceSource.TraceEvent(TraceEventType.Error, TraceEventId.UnhandledException, traceMessage);

 // Don't modify result if custom errors not enabled
 //if (!filterContext.HttpContext.IsCustomErrorEnabled)
 // return;

 // We only handle actions with return type of JsonResult - I don't use AjaxRequestExtensions.IsAjaxRequest() because ajax requests does NOT imply JSON result.
 // (The downside is that you cannot just specify the return type as ActionResult - however I don't consider this a bad thing)
 if (actionMethodInfo.ReturnType != typeof(JsonResult)) return;

 // Handle JsonResult action exception by creating a useful JSON object which can be used client side
 // Only provide error message if we have an MySpecialExceptionWithUserMessage.
 var jsonMessage = FooHandleErrorAttributeResources.Error_Occured;
 if (filterContext.Exception is MySpecialExceptionWithUserMessage) jsonMessage = filterContext.Exception.Message;
 filterContext.Result = new JsonResult
 {
 Data = new
 {
 message = jsonMessage,
 // Only include stacktrace information in development environment
 stacktrace = MyEnvironmentHelper.IsDebugging ? filterContext.Exception.StackTrace : null
 },
 // Allow JSON get requests because we are already using this approach. However, we should consider avoiding this habit.
 JsonRequestBehavior = JsonRequestBehavior.AllowGet
 };

 // Exception is now (being) handled - set the HTTP error status code and prevent caching! Otherwise you'll get an HTTP 200 status code and running the risc of the browser caching the result.
 filterContext.ExceptionHandled = true;
 filterContext.HttpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError; // Consider using more error status codes depending on the type of exception
 filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);

 // Call the overrided method
 base.OnException(filterContext);
 }

 /// &lt;summary&gt;
 /// Does anybody know a better way to obtain the controller action method info?
 /// See http://stackoverflow.com/questions/2770303/how-to-find-in-which-controller-action-an-error-occurred.
 /// &lt;/summary&gt;
 /// &lt;param name="exception"&gt;&lt;/param&gt;
 /// &lt;returns&gt;&lt;/returns&gt;
 private static MethodInfo GetControllerAction(Exception exception)
 {
 var stackTrace = new StackTrace(exception);
 var frames = stackTrace.GetFrames();
 if(frames == null) return null;
 var frame = frames.FirstOrDefault(f =&gt; typeof(IController).IsAssignableFrom(f.GetMethod().DeclaringType));
 if (frame == null) return null;
 var actionMethod = frame.GetMethod();
 return actionMethod as MethodInfo;
 }
 }
}
</code></pre>

I've developed the following jQuery plugin for client side ease of use:

<pre><code>(function ($, undefined) {
 "using strict";

 $.FooGetJSON = function (url, data, success, error) {
 /// &lt;summary&gt;
 /// **********************************************************
 /// * UNIK GET JSON JQUERY PLUGIN. *
 /// **********************************************************
 /// This plugin is a wrapper for jQuery.getJSON.
 /// The reason is that jQuery.getJSON success handler doesn't provides access to the JSON object returned from the url
 /// when a HTTP status code different from 200 is encountered. However, please note that whether there is JSON
 /// data or not depends on the requested service. if there is no JSON data (i.e. response.responseText cannot be
 /// parsed as JSON) then the data parameter will be undefined.
 ///
 /// This plugin solves this problem by providing a new error handler signature which includes a data parameter.
 /// Usage of the plugin is much equal to using the jQuery.getJSON method. Handlers can be added etc. However,
 /// the only way to obtain an error handler with the signature specified below with a JSON data parameter is
 /// to call the plugin with the error handler parameter directly specified in the call to the plugin.
 ///
 /// success: function(data, textStatus, jqXHR)
 /// error: function(data, jqXHR, textStatus, errorThrown)
 ///
 /// Example usage:
 ///
 /// $.FooGetJSON('/foo', { id: 42 }, function(data) { alert('Name :' + data.name); }, function(data) { alert('Error: ' + data.message); });
 /// &lt;/summary&gt;

 // Call the ordinary jQuery method
 var jqxhr = $.getJSON(url, data, success);

 // Do the error handler wrapping stuff to provide an error handler with a JSON object - if the response contains JSON object data
 if (typeof error !== "undefined") {
 jqxhr.error(function(response, textStatus, errorThrown) {
 try {
 var json = $.parseJSON(response.responseText);
 error(json, response, textStatus, errorThrown);
 } catch(e) {
 error(undefined, response, textStatus, errorThrown);
 }
 });
 }

 // Return the jQueryXmlHttpResponse object
 return jqxhr;
 };
})(jQuery);
</code></pre>

What do I get from all this? The final result is that

<ul>
<li>None of my controller actions has requirements on HandleErrorAttributes.</li>
<li>None of my controller actions contains any repetitive boiler plate error handling code.</li>
<li>I have a single point of error handling code allowing me to easily change logging and other error handling related stuff.</li>
<li>A simple requirement: Controller actions returning JsonResult's must have return type JsonResult and not some base type like ActionResult. Reason: See code comment in FooHandleErrorAttribute.</li>
</ul>

Client side example:

<pre><code>var success = function(data) {
 alert(data.myjsonobject.foo);
};
var onError = function(data) {
 var message = "Error";
 if(typeof data !== "undefined")
 message += ": " + data.message;
 alert(message);
};
$.FooGetJSON(url, params, onSuccess, onError);
</code></pre>

Comments are most welcome! I'll probably blog about this solution some day...

blocks|key|345005|text|对于服务器/协议错误，我会尽量使用REST/HTTP+(与您在浏览器中键入URL进行比较)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|345006|不存在的项被称为(/|345007|/{-id-|unordered-list-item|345008|})。返回404。|345009|服务器上发生意外错误(代码错误)。返回500。|345010|客户端用户未被授权获取资源。返回401.|345011|345012|345013|对于域/业务逻辑特定的错误，我会说协议的使用方式是正确的，并且没有服务器内部错误，因此以错误JSON/XML对象或任何您喜欢用来描述数据的错误作为响应(将其与在网站上填写表单进行比较)：|345014|345015|用户想要更改其帐户名，但该用户尚未通过单击发送给该用户的电子邮件中的链接来验证其帐户。|345016|+{"error":"Account+not+verified"}或其他任何东西。|345017|用户想要订购图书，但图书已售出(在数据库中状态已更改)，无法再订购。Return+{“error”：“图书已售出”}。|345018|345019|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|14|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|15|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|S|5|F|7|1A|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1B|8|@]|9|@]|A|$]]|$1|V|3|W|5|F|7|1C|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|Z|$]]

For server/protocol errors I would try to be as REST/HTTP as possible (Compare this with you typing in URL's in your browser):

<ul>
<li>a non existing item is called (/persons/{non-existing-id-here}). Return a 404.</li>
<li>an unexpected error on the server (code bug) occured. Return a 500.</li>
<li>the client user is not authorised to get the resource. Return a 401.</li>
</ul>

For domain/business logic specific errors I would say the protocol is used in the right way and there's no server internal error, so respond with an error JSON/XML object or whatever you prefer to describe your data with (Compare this with you filling in forms on a website):

<ul>
<li>a user wants to change its account name but the user did not yet verify its account by clicking a link in an email which was sent to the user. Return {"error":"Account not verified"} or whatever.</li>
<li>a user wants to order a book, but the book was sold (state changed in DB) and can't be ordered anymore. Return {"error":"Book already sold"}.</li>
</ul>

blocks|key|345069|text|是的，您应该使用HTTP状态代码。并且最好以某种标准化的JSON格式返回错误描述，如Nottingham’s+proposal，请参阅apigility+Error+Reporting|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|345070|345071|接口问题的负载结构如下：|blockquote|345072|345073|345074|关于描述错误条件的文档的|345075|type：(可选，如果未提供，则假定为“about:空白”；应解析为人类可读的文档；Apigility始终为this).|unordered-list-item|style|BOLD|345076|title：提供错误条件的简短标题(必需；并且对于相同类型的每个问题应相同；Apigility始终向this).|345077|status：提供当前请求的状态码(可选；适应性始终提供特定于此请求的this).|345078|detail：错误详细信息(可选；对于标识此问题的特定实例的每个problem).|345079|instance：URI，适应性都需要此详细信息(可选；Apigility当前不提供此信息)。|345080|345081|entityMap|0|LINK|mutability|MUTABLE|url|https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem|1|https://apigility.org/documentation/api-primer/error-reporting^0|16|L|0|1V|P|1|0|0|0|0|0|0|0|4|0|0|5|R|T|0|0|E|0|0|6|0|0|8|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]|$A|1D|B|1E|1|1F]]|C|$]]|$1|D|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1H|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1K|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|1L|8|@$A|1M|B|1N|O|P]]|9|@]|C|$]]|$1|Q|3|R|5|N|7|1O|8|@$A|1P|B|1Q|O|P]|$A|1R|B|1S|O|P]]|9|@]|C|$]]|$1|S|3|T|5|N|7|1T|8|@$A|1U|B|1V|O|P]]|9|@]|C|$]]|$1|U|3|V|5|N|7|1W|8|@$A|1X|B|1Y|O|P]]|9|@]|C|$]]|$1|W|3|X|5|N|7|1Z|8|@$A|20|B|21|O|P]]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|22|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|23|8|@]|9|@]|C|$]]]|10|$11|$5|12|13|14|C|$15|16]]|17|$5|12|13|14|C|$15|18]]]]

Yes, you should use HTTP status codes. And also preferably return error descriptions in a somewhat standardized JSON format, like <a href="https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem" rel="nofollow noreferrer">Nottingham’s proposal</a>, see <a href="https://apigility.org/documentation/api-primer/error-reporting" rel="nofollow noreferrer">apigility Error Reporting</a>:
<blockquote>
The payload of an API Problem has the following structure:
<ul>
<li>
type: a URL to a document describing the error condition (optional, and "about:blank" is
assumed if none is provided; should resolve to a human-readable document; Apigility always
provides this).</li>
<li>
title: a brief title for the error condition (required; and should be the same for every
problem of the same type; Apigility always provides this).</li>
<li>
status: the HTTP status code for the current request (optional; Apigility always provides this).</li>
<li>
detail: error details specific to this request (optional; Apigility requires it for each
problem).</li>
<li>
instance: URI identifying the specific instance of this problem (optional; Apigility currently
does not provide this).</li>
</ul>
</blockquote>

I'm writing a JSON service in C# (.ashx file). On a successful request to the service I return some JSON data. If the request fails, either because an exception was thrown (e.g. database timeout) or because the request was wrong in some way (e.g. an ID that doesn't exist in the database was given as an argument) how should the service respond? What HTTP status codes are sensible, and should I return any data, if any?

I'm anticipating that service will mainly be called from jQuery using the jQuery.form plugin, does jQuery or this plugin have any default way of handling an error response?

EDIT: I've decided I'll use jQuery + .ashx + HTTP [status codes] on success I'll return JSON but on error I'll return a string, as it appears that that is what the error option for jQuery.ajax expects.

What should a JSON service return on failure / error

数据库

服务器

jQuery

JSON

我正在用C# (.ashx文件)编写一个JSON服务。在对服务的成功请求中，我返回一些JSON数据。如果请求失败，无论是因为抛出了异常(例如，数据库超时)，还是因为请求在某种程度上是错误的(例如，给出了一个不存在于数据库中的ID作为参数)，服务应该如何响应？哪些HTTP状态代码是合理的，我应该返回任何数据吗？我预计服务...

问JSON服务在出现故障/错误时应该返回什么
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JSON服务在出现故障/错误时应该返回什么EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JSON服务在出现故障/错误时应该返回什么
EN