Ember.js: 中止的过渡将错误传播到Ember.RSVP.on（'error'，...）

@ofbriggs我最好的猜测是此提交//github.com/emberjs/ember.js/commit/94e1035a0eb66cc4d2a6624ff2557a331524f663大约28天前解决了大约TransitionAborted也许@chancancode或@rwjblue可以回答这个问题题。

我怀疑我的承诺改变了该特定行为，但我个人认为最好不要将其传播给RSVP，尽管我不确定到底是什么改变了。

下周我可能会研究一些相关的内容（路线检测），所以如果到那时为止还没有人弄清楚，我可能会发现为什么将其作为这项工作的一部分。

似乎某些内部人员没有处理拒绝，这应该被视为错误。

如果拒绝是在同一回合中处理的，则不会传播到on('error

这事有进一步更新吗？ 我也在Ember 2.2.0中体验过。

现在，我只是将错误的名称硬编码为一种解决方法。

export default function onServerError(cb) {
  Ember.RSVP.on('error', (reason) => {
    // An aborted transition propogates an error to RSVP
    if(reason.name !== 'TransitionAborted') {
      cb(reason);
    }
  });
}

有什么进展吗？ 我们也在Ember 2.3上遇到了这个问题。

+1

我们的错误跟踪平台Sentry遇到了同样的问题，并通过此提交中的解决方法解决了

+1

+1

+1

谢谢@stravid ，这正是我所需要的。 几个月的错误后，经过Google-fu的努力，我终于找到了这个线程和您的解决方法。 🙇

感谢@devinus的客气话，我将尝试写一些博客文章，以便将来不需要那么多的Google-fu :)

感谢@stravid ，但这仍然不是解决方案，也许我们可以在错误回调中添加更多的参数，以检查模型的请求是否失败。

我刚刚在ember-cli-sentry https://github.com/damiencaselli/ember-cli-sentry/pull/67中合并了一个修复程序

在Ember 2.5中经历过（我们正在更新Ember版本）。
为了将来参考，我建议使用ember-cli-sentry ^。

在我们发现错误的根源之前，由于虚假警报的数量，加上什至一个下午/晚上，我们甚至不得不升级哨兵订阅。

我也花了一些时间弄清楚这是一个误报错误。

在指南和API中记录了在redirect transitionTo内使用
https://emberjs.com/api/ember/2.18/classes/Route/methods/redirect?anchor=redirect

尽管如此，它仍然会产生一个错误：
https://ember-twiddle.com/41c21d19e962b4981c967e46228452bb

这将节省大量emberjs新手的时间

@chancancode或@rwjblue计划对此行为进行任何更改？
我们在beforeModel()中有一名后卫过渡到另一条路线时看到了这一点。
我们仍然在Ember 2.16上看到它

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak @ victor95pc应该还是这个问题， ， 你怎么看？

如今，我几乎不使用Ember，但是我想您可以尝试通过分叉并更新Ember版本来重现它？
http://emberjs.jsbin.com/wiruqobiqe/1/edit？输出

与@bichotll一样，我最终做了后端工作，现在对Ember的使用不再多了。 我会让你们决定对这个有什么好处。 :)

我没有机会测试

我停止使用Ember，因此无法确认它仍然是一个问题。

似乎仍然是一个问题： https :

是的，这仍然是一个问题（已通过ember-3.5.0测试）。

仍在3.8中看到

在3.10.0上复制： https :

在2.18.2上+1

对于浏览器错误，这似乎更多是噪音问题。 但是，使用Fastboot会变得更加困难，因为抛出将停止所有操作。 我还没有找到捕获该特定错误的方法，并且我怀疑问题是该异常被抛出到Promise错误处理程序中。

出于好奇，该次掷球有什么价值？ 我想知道是否可以将其删除，或者是否可以移动错误处理程序以使其被覆盖。

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak @ victor95pc应该还是这个问题， ， 你怎么看？

@pixelhandler仍然是一个问题-我可以在Ember 3.8.3上重现它。 我认为我们应该考虑删除inactive标签，尤其是@robgarden提供的用于复制的

我同意。 这是很烦人的问题。 如果您正在测试过渡是否已中止，它还会阻止测试

我们的catch语句可能会中止转换，请明确检查该错误。 虽然还是很痛...

要回答的问题是，如果我们是否关心TransitionAbortedError ，它是否可以我们希望报告异常的方式发生？ 知道何时重定向用户可能很有用（对于用户或不良UX，这通常是意外行为，当用户单击某些内容时，用户应该知道他们要去往何处）。

在许多情况下，在重定向用户并使用重定向作为最后手段之前，您应该考虑用户的去向。 我认为那些报告的“虚假”错误实际上是不良UX设计的迹象。

当然，我受到此问题的影响，因为在许多情况下，直到模型钩子触发后，您才知道如何引导用户……例如后端上的字段已更改。 仍然可以向用户提供有关过渡的反馈，而不是无声地重定向他们。

因此，我认为抛出它们是一件好事，它使您有机会向用户发出意外过渡的警报，并提醒您可以改善用户体验的地方。

@ezpuzz分层授权（不是身份验证）是我们经常遇到的一个问题。 我们存储过渡以供以后使用，以便我们可以提供良好的UX，并减轻开发人员在实现路由时的痛苦。 在命中之前，我们不知道哪些路由需要提升的权限，在这种情况下，我们会中止并在重试之前要求提升的凭据。 笼统的说法是，在许多情况下它是糟糕的UX，这是错误的说法。

还要注意，此错误在异步块中引发，未卸载到rsvp.on（'error'

另外，如果您不重写RSVP.on('error')此代码将运行，从而吞噬错误： https :

@ James1x0抱歉，我的意思是，在某些情况下会

在那种情况下，我们可以在这里提高错误的有效性： https :

通过在此处传递有关过渡的更多信息： https :

否则，可以忽略不计，就像我在上一条评论中提到的那样。