On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller <[email protected]> wrote:
> > > > On Wed, Nov 13, 2013 at 8:20 AM, David Bruant <[email protected]> wrote: > >> 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. > > > Hi David, I don't understand what you mean by "it" above. Because the > question is undecidable, we need approximations. The two approximations > that seem good are those that never have false negatives with few false > positives, and those that never have false positives with few false > negatives. They would bound the undecidable question from above and below. > AFAICT, these are the two we've already discussed: > > * The console approach Domenic has previously described captures the > approximation "no one has yet set any reject callback on". > * The finalization-based approach Kris explained captures the > approximation "no one can even set any reject callback on because the > promise is unreachable". > "can even set" should be "can ever set". > * And finally, the .done() operation provides even better accuracy at the > price of asking programmers to more explicitly state their intent. > > Do you have in mind some way to better approximate the undecidable > question than these? Do you have some way to do as well as, or better than, > the second bullet without observing GC decisions? > > > >> 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 >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
