Le 13/11/2013 08:11, Boris Zbarsky a écrit :
> On 11/13/13 10:58 AM, David Bruant wrote:
>> I'm sympathetic with this use case, but Weakrefs seem like the wrong
>> tool to solve this problem.
>
> I think I agree on that.
>
>> Ideally, the ECMAScript error sink would handled both uncaught thrown
>> errors and unhandled promise errors.
>
> Defining "unhandled promise error" is not trivial, actually, unless 
> you just mean "rejected promise that no one ever sets any reject 
> callbacks on".
That would be my definition. "no one ever sets any reject callback on" 
is itself undecidable (the "ever" part), but I feel it works well enough 
in practice. Cases where it doesn't, people have memory leaks. 
Domain#intercept which looks at the Node error convention (error in  
async callback first argument) certainly suffer from the same issue, but 
looks practical enough. I lack the experience with Node domains. If some 
have it, it'd be interesting to share it.

David

Le 13/11/2013 08:11, Boris Zbarsky a écrit :
> Defining "unhandled promise error" is not trivial, actually, unless 
> you just mean "rejected promise that no one ever sets any reject 
> callbacks on".

That would be my definition. "no one ever sets any reject callback on" 
is itself undecidable (the "ever" part), but I feel it works well enough 
in practice. Cases where it doesn't, people have memory leaks. 
Domain#intercept which looks at the Node error convention (error in  
async callback first argument) certainly suffer from the same issue, but 
looks practical enough. I lack the experience with Node domains. If some 
have it, it'd be interesting to share it.