It's a real pain to guarantee that you will always get an answer back about whether some asynchronous operation succeeded or failed. Every callback needs to manually trap its own exceptions, manually listen for exception reports from the subsequent callbacks that it dispatches, and report it all back to the original caller.

There are libraries that make this better (example: https://github.com/kriskowal/q). But since they're not built into the language itself, you end up with more verbose code that's harder to debug when it breaks, and you can't easily interoperate with other code that uses a different flow control library.

There are lots of ways to design a language so that it doesn't suffer this problem. If you simply built an API like Q's into the spec for Javascript so that it had nice syntax and everyone could interoperate using it, that would be a minimum viable solution that retains all Javascript's existing performance characteristics. Alternatively, you can have real coroutines which I think would be even better, though that does change the memory-usage patterns more significantly.

OP probably means the chaining of several async calls. Atleast in Node, the convention is to bubble up an err object back if any of the functions throw up. If you let an exception to throw, then the Node process crashes. There is a global catch-all error event listener, but it's use is generally discouraged.