Promises and Decidability in Asynchronous Error Handling

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Mon Oct 21 13:29:05 PDT 2013


I don't think that's the same thing at all.

Detecting an infinite loop is _extremely_ hard at most cases (and of course
impossible at others. However instead of discussing the halting problem, I
think what's bothering this guy is that `.then` does not throw an error
when an error occurs within it even if that error is completely unhandled
by the promise flow.

Different libraries that implement promises handle errors differently. For
example bluebird[0] writes the stack trace to stderr (or console.error) if
the rejection is unhandled by the start of the second turn. I quote: "your
quote doesn't work as expected and you open console and see a stack trace :
nice".

On that topic, I'd appreciate some reading on promises being added to the
spec of the language (since when does the ES language spec even deal with
concurrency? I thought that was a part of the host environment.

[0]: https://github.com/petkaantonov/bluebird#error-handling

Domenic Denicola <domenic at domenicdenicola.com> wrote
> A well-known problem with loops, as implemented in various programming
languages, is that infinite loops are silenced by default. Consider the
following program, which simply adds some numbers in a loop:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131021/1e0f4f40/attachment-0001.html>


More information about the es-discuss mailing list