The first-parameter convention only works for application errors and errors from libraries that also follow the convention. Everything else, including the JS runtime, throws exceptions whether we like it or not. So either you have to make sure that your code never triggers any of those—which is a pretty tall order—or put try/catches around everything, even if your own code doesn't throw any exceptions. That's more than a bit harder to manage—if you do it correctly, there are so many try-catch blocks that the rest of the code almost gets drowned out by them. In my observation, most people deal with this by sacrificing a certain amount of error safety in order to make the code more tractable.

It seems like the kind of problem that is better dealt with by a compiler.

Promises help with this quite a lot. http://promises-aplus.github.io/promises-spec/ What 3.2.6.2 means is that any thrown exception is caught and turned into a rejected promise which will bubble up (across async boundaries) until it gets to a rejection handler.

I haven't had too much experience with Domains, but I believe they are generally used for courser grain error handling (because it's a bit verbose to attach them all over the place). E.g., to catch most errors (it's no guarantee what 3p libs do to your context) generated in fulfillment of a particular web request.

Can promises guarantee that condition with only library code? or do you still have to have try/catch in the application code, and if so where?

Also, do any of the promises libraries solve the backtrace problem, and if so how do they do it?

Unfortunately putting a try/catch around a 3p lib doesn't actually capture exceptions generated by those libs (unless they occur before any async operations, which I would say is the exception rather than the rule).

You're right that you have to manage exceptions, which is difficult. The biggest problem I've had with Node is the runtime exceptions that crash the entire process because they go uncaught. To deal with that, I have the server automatically restart on failure - far from an ideal scenario of error recovery (and what I think you're referring to when you talk about sacrificing error safety).