W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

Re: Promises and Decidability in Asynchronous Error Handling

From: K. Gadd <kg@luminance.org>
Date: Mon, 21 Oct 2013 12:26:14 -0700
Message-ID: <CAPJwq3XLZgBzYU_WejzG=thyL=o8kN347NhtP+rRFTbXmfioMg@mail.gmail.com>
To: Kevin Smith <zenparsing@gmail.com>
Cc: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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
Received on Monday, 21 October 2013 19:27:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC