If you do that, don't be surprised when window.onerror seems to be complete shit and not provide a fraction of the information you need: window.onerror is complete shit and does not provide a fraction of the information you need.
If an exception is thrown anywhere, window.onerror will only get you the exception message, file and line (the latter two being utterly useless in minimized code of course).
If you can, wrap all behaviors (meaning all event callback as well) in a try/catch, so you can get the actual error object and hopefully extract useful informations from it (or the environment, this pattern also allows you to log and report the initial state which ultimately lead to the fault).
I thought the same thing. I'd expect the developer who is thoughtful to catch client-side errors would also deploy their code minified and that JS errors are infamously unidentifiable by message alone (unexpected reference to undefined, anyone?).
I think this could be helpful given some savvy javascript written expressly to be parsed on error - but the overhead that may bring on doesn't seem worth it. And with enough users you may have a deluge of data to sift through.
If an exception is thrown anywhere, window.onerror will only get you the exception message, file and line (the latter two being utterly useless in minimized code of course).
If you can, wrap all behaviors (meaning all event callback as well) in a try/catch, so you can get the actual error object and hopefully extract useful informations from it (or the environment, this pattern also allows you to log and report the initial state which ultimately lead to the fault).