What you say is true and I don't disagree with it, but we're talking about different levels of abstraction. Yes, at a lower level there is a technical differenc

What you say is true and I don't disagree with it, but we're talking about different levels of abstraction. Yes, at a lower level there is a technical difference, but if you zoom out far enough, the result is not different, i.e. in both cases the feature does not work. I understand and agree with what you are saying about failing fast and hard being more convenient to catch bugs, as an engineer, but then we get into what is a bug and what can be ignored? If the result is a mission critical feature breaking, you can't ignore that. Inversely, if you can ignore it, then it isn't mission critical. So my point was, at a higher level of abstraction they are the same thing. The cause is forgetting to handle an Error in your code, the effect is a feature breaking. Regarding that cause then, the OP was saying that it's easier to forget chaining a .catch(), but that is only assuming that you'd actually remembered to use a try in your async/await code, i.e. you are aware of the fact it might throw. I can't think of many times where I have been aware something might throw and forgotten a .catch(), but for some reason would have remembered to wrap the call with a try, were it async/await code. I guess I am saying it's unclear to me how try/catch helps one remember to handle Errors, over .catch(). Seems like the syntax is not the issue, the issue is not being aware or ignoring that the code might throw in the first place. Obviously, this is all dependent on context and application and both perspectives are 'right' for different scenarios.