- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 15 May 2013 08:54:23 +0100
- To: Sean Hogan <shogun70@westnet.com.au>
- CC: public-script-coord@w3.org
Le 15/05/2013 00:19, Sean Hogan a écrit : > On 14/05/13 10:29 PM, David Bruant wrote: > >>>> The purpose of done is to avoid a to chain so that uncaught errors >>>> aren't propagated without being caught. When you call .done and the >>>> last promise had an error, the devtools can tell you so (telling >>>> you before .done could be confusing as the error might be later >>>> caught) >>>> >>> >>> `.done()` **does not** provide a guarantee against silent failure. >> It does in the Q library. It will also with native support in >> combination with devtools. > > I can't see how the current spec supports that. That's not the spec role to talk about what's possible for devtools > Are you saying devtools will do something like the following? > > Future.prototype._done = Future.prototype.done; > Future.prototype.done = function(acceptCB, rejectCB) { > this._done(null, function(err) { throw err; }); > this._done(acceptCB, rejectCB); > } They could, but I hope not (I'm not a big fan to throw the exception at runtime globally). The problem that I'd love to be solved is async error debugging. If you do the following: var f2 = f.then(function(){ throw new Error("whatever") }) Then f2 is supposed to be in the "rejected" state. Very much like for when an error is throw, we'd like to see this error appear in the console eventually (and as quick as possible) If further down the code, you have: f2.catch(...) Then devtools don't need to log the error, because you're handling it (like for try/catch. The error isn't logged) But whether you'll be calling f2.catch at some point, the runtime can't know. Whether the error will be propagated (f3 = f2.then(...)) and handled later down the road can't be known by the runtime either. For sure, the runtime knows that the error in f2 won't be handled when the error wasn't propagated and f2 is GC'ed. But f2 may never be GC'ed or may be GC'ed, but late, so that's not a really reliable idea. Calling f2.done() is a way for the developer to say "Don't propagate the error if any" so that devtools can log the error (but as I'm saying that, I realize there is a minor flaw. I need to think about it more...) Is the intent of .done clearer? David
Received on Wednesday, 15 May 2013 07:54:51 UTC