domenic at domenicdenicola.com (2013-11-17T18:11:17.741Z)
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant <bruant.d at gmail.com> wrote: > 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". * 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?
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". * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131113/49712f15/attachment.html>