Javascript HTTP状态代码-Backbone.js和Jquery

Backbone.js有一个简洁的功能，您可以使用标准HTTP谓词将更改同步回服务器

例如，您可能有一个模型对象和一些执行get的代码：

var coolModel = Backbone.Model.extend({url:'mysite/mymodel'});
var myCoolModel = new coolModel();
myCoolModel.fetch({error:processError});

在服务器返回4XX或5XX的情况下，错误函数“processError”会运行，这很好，您可以以任何适合的方式处理错误

由于backbone.js使用jQuery执行GET，jQuery会报告错误，事实就是如此。4XX是一个有效的错误，应该从中恢复，我的客户端应用程序没有损坏，它只是需要稍微不同的行为

---

我的问题是-在浏览器控制台窗口或状态栏中显示jQuery时引发此错误是否被认为是不好的做法？我是否应该以某种方式抑制此错误，以便生产中的用户在错误可恢复时不会看到浏览器报告的错误？或者，在HTTP的土地上，让它保持原样是正确的吗？

我想说，HTTP状态代码存在是有原因的，如果其原因是有效的，则完全有效，因此，是的，只需使用它们。但是：

400

表示

错误请求

，表示输入语法错误。您应该发送更多信息（如冲突的

409

，失败的前提条件的

428

，等等）。我正在努力想出一个有效使用

418的项目我是一个茶壶，但总有一天我会成功的

任何对站点内部工作感兴趣的人都可以查看控制台，但这应该没有问题，也不应该过分追求干净的外观，只要确保自己的流程是合理的。
主干中的错误处理是一个非常有趣的话题，我希望在某个时候写一写。以非突兀的方式直观地向用户指出错误是非常好的。需要考虑的是：


您的用户没有查看状态栏或开发人员工具
您的用户期望您的应用程序具有特定的行为
当您的应用程序无法正常运行时，可视问题指示器非常重要

我建议考虑故障如何影响用户的意图。例如，如果他们正在获取第一页的数据，而该数据没有正确返回，则需要通过显示检索到的数据失败来处理错误（或者更好地使用以前从缓存加载的数据…如果它存在的话）。如果打算保存一个项目，并且返回的错误代码为400，那么肯定不是成功的，并且应该指出用户应该再次尝试保存（或者可能在某个时间间隔内尝试重新保存）

您可以默默地忽略错误而不指出它们，但您的用户会感到困惑，这将导致意外的问题。我不能鼓吹使用完美的错误处理，因为我自己在这方面仍在进步。
如果您有模型验证，并且您的服务器端脚本工作正常，那么您不应该看到这些错误。在任何情况下，如果用户没有因为错误的输入等原因导致这些错误，请不要向用户显示这些错误。jQuery真的会向控制台报告错误吗？或者您是指浏览器调试工具的网络面板，在那里可以看到状态代码？谢谢。我可能不太清楚。我会修正我的问题。我认为使用状态码是一条很好的路，而不是使用哪种状态码的问题。我的问题是，抑制此错误是否合适，以便生产中的用户在错误可恢复时不会看到浏览器报告的错误。“正常”用户不会看到任何错误。。控制台“打开”的用户不是普通用户。这就像你是一名出租车司机，而你的客户打开你的汽车引擎盖来评估你的引擎：这并不是真的发生。还是我还是在某个地方漏掉了重点？