Every async operation can potentially fail. And one obvious way is: a timeout. It is very unlikely you want your async operation to last forever. So sometimes y

Every async operation can potentially fail. And one obvious way is: a timeout. It is very unlikely you want your async operation to last forever. So sometimes you need to specify that timeout and clean up everything afterwards (e.g: close handles to files or connections, unsubscribe event handlers, or anything necessary to not produce a leak), as well as log whatever happened and propagate errors in a controlled manner. Having this said, what is very lacking in most programming blog posts is the error handling portion, which is important. Errors happen all the time, and nothing is 100% reliable. Hardware is unreliable, networks are unreliable, input is unreliable... And this needs to be reflected in your code. Some communities understand that code snippets from blog posts are not production code. But doesn't seem to be the case in the node community. The impact of that is that is that now: - npm is full of modules that do not handle their own errors - many node applications lack robustness, bringing back reputation to node. e.g: not taken seriously as a platform language just as a throwaway orchestration layer and doing monkeying with JSON. - lack of error handling is mistakenly seen as elegance and simplicity. in reality it's lack of skill, seniority and responsibility - node module descriptions have more happy emojis and hyped superlatives than actual useful descriptions of how error conditions are handled - consuming a node module today is playing Russian roulette each time you upgrade a version I really hope the community takes a turn towards making code more robust and that could start in the blogosphere, talks, etc. But javascript is now the lingua franca of people that do not care about error handling and that is sad.