I just bumped into a javascript problem that exceeds the stupidity of previous ones:
Because promises can be retained after they settle, and handlers attached thereafter are pushed on the microtask queue, a promise rejection can't be asserted to be unhandled until the promise in question is GC'd.
Of course this is nuts so engines will conclude that a promise rejection is unhandled if there are no handlers at the moment of rejection.
I hate this language.

Does that imply a race condition or am i just paranoid?

@Oktokolo I have yet to find a data race that logically can't be fixed, but otherwise they are painfully common.

Although that might also be because async functions always push on the microtask queue and never resolve immediately so concurrent chains of async operations (events propagating through a system, results traveling down the async call stack) can often cause weird effects like message handlers firing for a recently closed connection.

@homo-lorens
I meant having a promise finish and then be assumed finished by such an engine before you can attach the handler.

@Oktokolo Promises never resolve immediately as calling the resolve function also pushes on the microtask queue, so if you attach the handler synchronously then it's safe.

@homo-lorens
Then there should be no problem and i don't get your rant...

@Oktokolo There are times when I don't immediately know what I want to do with a promise so I just store it and build chains of "then" dynamically and interactively. This works great because, thanks to the reusable nature of promises, I can build my chains even after the events had happened and the handlers will execute soon after I place them. However if a chain fails before I find the appropriate error handler for it, that's an unhandled promise rejection.

With regular exceptions if you don't catch them you can't access them, and if you do catch them they're gone and won't cause any trouble unless you deliberately re-throw. With rejected promises though it's possible to both get an unhandled rejection and execute a rejection handler.

Now that I said all that I realised that this is the only way promise rejections make sense and I should know how to handle errors when I create the promise.

@homo-lorens
In my opinion, not knowing exactly what to do when some action fails is okay. But you should always know whom to ask or where to store that fact before you start.
For promises that indeed means, that it should always be known in advance whether failure has to be handled at all - and when yes, where to record it or who to call.

Also, JavaScript at its core is a nice functional scripting language, which sadly just happens to miss all the functional features that would actually make it a great language.
Promises wouldn't have been the first of them to add if one would have asked me (i would have chosen tail call optimization to support deeply recursive algorithms).
But promises are fancy and probably more relevant for web scripting.
So i guess their choise is justified.