Add info about non-interference of handlers

[briancavalier]

I had a twitter convo today with someone who couldn't tell from the current spec whether one handler could prevent another from being executed. For example, he was unsure if f2 would be executed in this scenario:

// let p1 be a fulfilled promise
p1.then(function f1() { throw new Error(); });
p1.then(function f2() {});

My feeling is that 3.2.2, 3.2.3, and 3.2.5.x are sufficient, and I pointed him to those. He still felt it wasn't obvious, so I wanted to pass along his concern to see whether others feel we should add something to clarify.

[avoidwork]

Hi,

I'm that someone, and I just wanted to add a little context. The rule is implicit; it really only comes across if you think of the problem a certain way, otherwise it becomes a question. If you defined the rule explicitly, there'd be no question during implementation, e.g. Errors thrown from a handler will not block execution of subsequent handlers

Of course, the issue could be I just looked at the problem another way and missed the implication. Regardless, if it's open to interpretation there's room for error. Adding another point at the right place would help greatly.

[briancavalier]

@avoidwork Thanks for the additional context! Were you coming at this as a user of promises, or as an implementer of promises (or both)?

[avoidwork]

A little of both. I'm writing the tool set (implementer) which I build on of (user). No one I work with has experience with the pattern beyond jQuery's version, and ... yeah.

[lsmith]

@avoidwork Would the insertion of the word "all" into 3.2.5.1 and .2 clarify enough?

If/when promise is fulfilled, all respective onFulfilled callbacks must execute in the order of their originating calls to then.

[avoidwork]

yup

[domenic]

Let's do that then, it's very easy and doesn't seem like it's overburdening the spec with non-normative language.

[briancavalier]

Sounds good to me as well. Since it doesn't seem to make the spec any less clear, and in fact, makes it more clear for at least one person, it seems like a good thing :)

[briancavalier]

I can do this when I get back to a keyboard in a bit if no one gets to it first.

[briancavalier]

Oops sorry for the double commit messages above. One is from my fork, but I decided just to make this change directly, as it seemed silly to pull request it since it was such a small change.