Re: Concerns about DOMRequest

Le 20/02/2013 23:38, Jonas Sicking a écrit :
> Semantically they might have different meaning, and technically the 
> platform might do different error reporting. But it's just as possible 
> for script to catch errors using .then() as it is to catch them using 
> .done() as the draft currently stands. / Jonas 
Completely. The only case where .done really matters is platform error 
reporting, I agree the script-catching story is exactly the same.
I understand that as an implementor, you feel .done is barely a .then 
without a return, but from an author standpoint, it really makes a huge 
difference.

Mounir Lamouri wrote:
> .done() gives some semantic but I do not think you need .done() to catch
> an error not being handled in the following chain:
> foo.then(function() {
>    return bar();
> }).then(function() {
>    return foobar();
> });
>
> In this chain, if an error has to be thrown, the backend will try to
> send it to the next member of the chain. If, until the end of the chain,
> there is no error handler, the backend could simply log that.
But the platform cannot know that the chain has ended. 
|foo.then().then()| returns a future and this future may be attached an 
error handler later. Arbitrarily later. This kind of things happen when 
you return a future from a function for instance; the .then/catch of the 
method isn't called right after the future creation.
In the code snippet you wrote, you know as a human being author that the 
chain has ended, because you haven't chained a call and you haven't 
stored the last future (in the variable/object property). But the 
platform does not have this knowledge.

In theory, the question "has this future chain ended?" (which is 
necessary to know if an error won't be handled) can be solved in 
different ways:
1) static(+dynamic) source analysis. Hopefully, we agree this is 
unicorn-ish.
Even if that was brought in the first iteration of implementing futures, 
there will always be cases where static analysis would be insufficient.
But that would probably catch most practical cases. Maybe enough to make 
.done not justified?
2) Wait for the effectively last future of a chain to be GC'ed (if it's 
GC'ed and contains an unhandled not-forwarded error, the chain has ended 
and the error can be reported). We probably agree there are limitations 
to waiting for GC to get error reporting.
3) Ask the user to say explicitly where the chain ends. The Q library 
does it by defining a .done method on promises. In practice, that makes 
the code readable; that works, so I suggest just reusing this idea.

If you have another idea (and implementation :-p) of how to prove a 
future chain has ended or a better way to express that the chain has 
ended, I think the door is open to removing .done.
In essence, don't remove .done unless you have something at least as 
good to help async debugging.

David

Received on Thursday, 21 February 2013 09:00:31 UTC