This could break people relying on unhandled rejections never being real exceptions. To be non-breaking we could add a$unhandledRejectionHandler service that takes a rejection, and delegates to$exceptionHandler this way I could add a handler that passes the exception directly but the default would be to strip the error and tasty tracebacks

Actually, the "juicy info" does already exist. It is just stringified into a less juicy{} (which we need to fix).
Closing as duplicate of#14631.

@gkalpak stringifying the exception breaks trace-back info because angular doesn't stringify errors properly.

Angular calls Errors 'exceptions' and brutally stringifies them before they can be safely carried to the gentle, sweet, embrace of window.onerror.

@gkalpak no it doesn't.

Nobody wants angular to mess with their Errors and turn them into 'exceptions' for the$exceptionHandler

re-opened for your delectation and delight at#15527

That's what I meant by "we need to fix it". Embarrassing as it may be, I have to admit I did not realize this was a PR, until now. I thought it was an issue 😳

Sorry, for not paying attention and thx for your perseverance. I promise I'll treat#15527 rightly 😛