domenic at domenicdenicola.com (2013-11-17T18:11:39.562Z)
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller <erights at google.com> wrote: > * 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".
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller <erights at google.com> wrote: > > > > On Wed, Nov 13, 2013 at 8:20 AM, David Bruant <bruant.d at gmail.com> 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 >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131113/0efb9b01/attachment.html>