Le 13/11/2013 06:15, Boris Zbarsky a écrit :
> On 11/12/13 11:07 PM, David Bruant wrote:
>> I understand the need to know when a promise has an unhandled error at
>> development time, I'm less clear on why you need to know it at runtime.
>> Why would you do with this information? handle the error?
>
> The same thing that sites (e.g. Facebook) do with window.onerror: 
> phone home to the server about the bug so it can actually get fixed.
I'm sympathetic with this use case, but Weakrefs seem like the wrong 
tool to solve this problem. Wrapping every single promise in case one 
ended up failing in an unexpected way feels way too expensive. There 
should be a sort of error sink feature instead.

The browser has window.onerror for historical reasons, Node.js 
introduced Domains and Domain#intercept [1] for that reason IIUC.
Isn't it the sign that ECMAScript should have this feature built-in?
A global sink has something absurd to it, what about adding an error 
sink feature to module loaders? cc'ing ES6 Module folks

Ideally, the ECMAScript error sink would handled both uncaught thrown 
errors and unhandled promise errors.

David

[1] http://nodejs.org/api/domain.html

Le 13/11/2013 06:15, Boris Zbarsky a écrit :
> On 11/12/13 11:07 PM, David Bruant wrote:
>> I understand the need to know when a promise has an unhandled error at
>> development time, I'm less clear on why you need to know it at runtime.
>> Why would you do with this information? handle the error?
>
> The same thing that sites (e.g. Facebook) do with window.onerror: 
> phone home to the server about the bug so it can actually get fixed.

I'm sympathetic with this use case, but Weakrefs seem like the wrong 
tool to solve this problem. Wrapping every single promise in case one 
ended up failing in an unexpected way feels way too expensive. There 
should be a sort of error sink feature instead.

The browser has window.onerror for historical reasons, Node.js 
introduced [Domains][1] and Domain#intercept for that reason IIUC.
Isn't it the sign that ECMAScript should have this feature built-in?
A global sink has something absurd to it, what about adding an error 
sink feature to module loaders? cc'ing ES6 Module folks

Ideally, the ECMAScript error sink would handled both uncaught thrown 
errors and unhandled promise errors.

[1]: http://nodejs.org/api/domain.html