To fix this information leak, some browser vendors (at least Google and Mozilla, I haven't checked anyone else) decided to make onerror check that the origin of the script causing an error matches the origin of the page. If the origins don't match then the error is sanitised to remove any potentially sensitive information: it becomes one the annoying "Script error" in "" on line 0. The origin of the script which registered the onerror is irrelevant, just the page and the script with an error matter.
This is significantly less than ideal.
Fortunately there's a proposed solution, which is implemented in Firefox and Opera, though doesn't seem to have found it's way into Chrome yet. That solution involves attaching crossorigin attributes to your script tags, and sending an Access-Control-Allow-Origin header with your scripts which will match your page's origin. As soon as you do that, your onerror (again, where that's registered from doesn't matter) will start getting useful information.
So, erm, yeah. What to do? I think you're basically stuck setting it to "*". This seems a tad sad. Any other option will run into problems with caching.
Update: since writing this I've raised the inability to make use of a list of origins as a bug on the W3C bugtracker. I fully expect a public mocking for this.