Re: Promises and Decidability in Asynchronous Error Handling

Requiring early registration prevents the use of futures as value
containers; i.e. kicking off an operation and storing the Future somewhere
so anyone can use it at a later date.

I agree that an improved error handling policy would be very, very good to
have, though.


On Mon, Oct 21, 2013 at 9:40 AM, Kevin Smith <zenparsing@gmail.com> wrote:

> 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 }
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>