Correct heading in We Have a Problem with Promises #6746
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We Have a Problem with Promises is still one of the best articles to send to folks struggling with promise idioms in the day of
async
/await
(I just sent it to somebody who was fiddling with nested promise constructors andasync
/await
, not because it addressed what they were doing directly but because the "do"s and "don't"s it discusses would give them better ways to structure their code, with or without the syntactic sugar ofasync
). But every once in a while I see people stumble over the statement that "catch() is not exactly like then(null, ...)". What is the difference explained in the article? Well, actually, that statement's the heading to a section that starts by explaining thatcatch
is exactly likethen
withnull
as the first callback parameter, then goes on to explain the difference betweenthen
followed bycatch
vsthen
with two callback parameters. And I just now realized I could submit a request on GitHub to make the heading reflect that!I was ambivalent about possibly using even shorter code in the heading:
then().catch()
andthen(..., ...)
as was the style before (as I said in the commit, I thought about it in terms of the shortest possible restatement of the section's content); but I figure it's easier to take the names back out than to find what the handlers were named elsewhere in the article in order to add consistent names in (which is what I did).Hope you like the suggestion! 馃樃