There's a difference: .then().catch() is worse because you can forget the .catch() part, and your error will be discarded unless you set up a global error handler (ugly because now the error will not bubble up properly). Not so with try ... catch.
Seems like in both cases, the cause is the same: you weren't aware or forgot that the async logic might throw, and so you don't write code to handle it.
Fail fast is an important principle, but in my opinion fail hard is fairly important too. If your program explodes every time a bug happens you're more likely to fix them. If it merely doesn't do the thing it's supposed to it's easy to miss and easier to ignore.
Indeed.
Having witnessed a couple of disastrous mishaps because someone didn't properly check return codes in their C code, I'd argue it's even worse than that. You can't predict the myriad of wrong ways your System will behave after an ignored error because things that were implicitly taken for granted aren't true anymore. And those are the types of errors that come with a great cost since a) you might not be aware of them the next few months and b) they are usually not easy to find in an automated fashion.
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.