Promises and Decidability in Asynchronous Error Handling

A well-known problem with Promises, as implemented in various Javascript
libraries, is that program errors are silenced by default.  Consider the
following program, which simply makes an HTTP request and then prints out
the HTTP response headers:

    fetchUri("http://someauthority.com/").then(response => {
        for (let header of repsonse.heders) // Note the misspelling!
            console.log(header.key, header.value);
    });

On line 2, the property "headers" is misspelled, which should cause the
program to report an unhandled error.  Under the current Promises
specification, however, the error will be silenced and the program will end
happily with success.

Various solutions have been proposed for dealing with this problem, such as:

- Extending debugging tools so that unhandled rejections are visible
through a specialized tab or view.

- Using the garbage collector to determine when rejections can no longer be
handled, and therefore constitute a program error.

- Adding a `done` method to the promise type which propagates rejections as
program errors.

While each of these approaches provides a partial solution to the problem,
they are ultimately inadequate because they do not address the underlying
cause.

The root cause of this issue is that, as currently specified, **the problem
of determining whether a particular runtime error has an associated handler
is Turing undecidable**.

This is *not* a desirable property for an error handling mechanism to have,
and it is not a design choice that can be reversed at a later date.

In order to make error handling decidable, it is sufficient to require that
an error handler must be attached to the promise *within a well-defined
window*.  One such window would be the lifetime of the currently executing
user call stack.

The designers of Dart have made a similar decision with their Future API.
 In the following document, users are instructed to register error handlers
"early":

https://www.dartlang.org/articles/futures-and-error-handling/#potential-problem-failing-to-register-error-handlers-early

A quick search on StackOverflow relating to Futures and "early" error
handling in Dart yielded no results.  This cursory evidence suggests that
requiring early registration of error handlers is not a significant problem
for Dart users.

In my view, it would be a mistake to standardize the undecidable error
handling model of current Promises design.

Thanks,

{ Kevin }