Miss Dada  🏳️‍⚧️

If I install an "onunhandledrejection" event handler that prints `e.reason.stack`, the "stack" only contains the error message; there's no actual trace. Can I get the trace somehow?

It seems like I can get it if I use Bluebird with "longStackTraces" enabled. Is using Bluebird in a new app a bad idea?

Oh, async/await always use native promises of course. Which means no solution that involves wrapping or any third-party promise library will work. Executing outside the main app's JS context is probably the only way to handle these errors properly. I dislike this.

Conclusion: there seems to be literally no way to execute some JavaScript code without promise rejection errors bubbling all the way up to the top of the execution context (window). And when they get to the top, there seems to be no way to tell where they came from.

Nothing is ever easy on the web.

I can't: - Overwrite Promise's constructor (async/await doesn't use it). - Use a third-party Promise library (same reason). - Use web workers (they can't access the DOM). I may be able to use iframes but I don't want to take that path now because it's a huge complication.

Nah, this doesn't seem that bad given the situation. Pragmatism to balance concerns like these is always welcome. Reminds me of https://github.com/rust-lang/rust/blob/3dbade652ed8ebac70f903e01f51cd92c4e4302c/src/libstd/time.rs#L205-L241 …