3

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 领域保持原样是正确的？

4

2 回答 2

2

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

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

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

您可以默默地忽略错误而不指出它们，但是您的用户会感到困惑，并且会导致意想不到的问题。我不能宣扬使用完美的错误处理，因为我自己仍然在这方面做得更好。

于 2012-06-28T22:12:33.843 回答
1

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

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

于 2012-06-28T21:49:35.297 回答