Finding out at runtime (by doing a sanity check in the finalizer) is a way to catch bugs in the application that were not caught at compile/development time, so you can log/report them and go back and fix them. This is an incredibly useful facility since (generally speaking) promise libraries have lots of opportunities for human mistakes to hide failures at runtime. When you have error handlers written properly for something like 95% of your promises, catching the other 5% when they rarely fail gets pretty complicated. Consider how a developer testing out some network code might only ever run the application in the office, so they'll never see the kind of exceptions you get when running an application over a modem. Getting useful diagnostic information when one of those rare exceptions isn't handled correctly lets you fix those problems without being able to necessarily reproduce them on demand.
On Tue, Nov 12, 2013 at 8:07 PM, David Bruant <[email protected]> wrote: > Le 12/11/2013 13:42, Kris Kowal a écrit : > > One of the concerns with promises is that they consume exceptions that >> may or may not be handled. I have been looking forward for WeakRef as one >> of the avenues available to mitigate this problem. A post-mortem finalizer >> would be able to surface an error that was trapped by a promise or promises >> that were eventually garbage collected, and therefore provably >> never-to-be-handled. >> >> It is true that this problem can be decisively mitigated in other ways, >> like requiring a promise to forward to a terminal "done()" in the same turn >> of the event loop, but I find this particular solution unpalatable. I do >> find a promise inspector compelling, one that will show an error until it >> is handled, but even in this case, I think it is compelling to visually >> elevate an unhandled error to a provably never-to-be-handled error, and >> this is not possible, at least outside chrome-space, without WeakRef. >> > 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? > If you think of wrapping promises in weakrefs, why not just add error > handling? > To me, it looks like the same amount of effort. > > David > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
