W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future feedback

From: David Bruant <bruant.d@gmail.com>
Date: Wed, 15 May 2013 08:54:23 +0100
Message-ID: <51933F2F.1080909@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC