Re: Promises and Decidability in Asynchronous Error Handling

wouldn't events better suit and better solve the problem ?

fetchUri("http://someauthority.com/").on('load', response => {
repsonse.heders() });

at least this is how it works in eddy.js and I've never had silent errors

in current specs would be an addEventListener() within the XHR object





On Mon, Oct 21, 2013 at 12:26 PM, K. Gadd <kg@luminance.org> wrote:

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