Question

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的土地上保留原样是正确的吗？

Answer 1

处理Backbone中的错误是一个非常有趣的话题，我希望在某些时候写一篇。以非突兀的方式向用户直观地指出错误是非常好的。需要考虑的一些事项是：

您的用户没有查看状态栏或开发人员工具
您的用户希望您的应用程序具有特定行为
当您的应用程序行为不正确时，视觉问题指标很重要

我建议考虑失败如何影响用户的意图。例如，如果他们正在获取第一页的数据并且数据未正确返回，则需要通过显示检索到的数据失败来处理错误（或者甚至更好地回退以前从缓存中加载的数据...它它存在）。如果目的是保存一个项目并且返回的错误代码是400肯定不成功，并且应该指示用户应该再次重试保存，（或者可能尝试在间隔上重新保存）。

您可以默默地忽略错误而不是指出错误，但是您的用户会感到困惑，这会导致意外问题。我无法宣传使用完美的错误处理，因为我自己还在改进它。

Answer 2

我会说HTTP状态代码是有原因的，如果它们的原因有效则完全有效，所以是的，只需使用它们。然而：400表示Bad Request，这意味着输入在语法上错误。您应该发送更多appropriate header（例如409用于冲突，428用于失败的前提条件，等等。我正在努力想出一个有效使用418 I'm a teapot的项目，但有一天我会成功...

任何对您网站内部工作感兴趣的人都可以看一下控制台，但是这应该没有问题，也不应该过度看待那里干净的外观，只需确保您自己的流程是合理的。

HTTP状态代码 - Backbone.js和Jquery

2 个答案: