I'd love that! Perhaps similar to what Node.js did with their `uncaughtException` event <http://nodejs.org/api/process.html#process_event_uncaughtexception>?
Sincerely, James Greene On Fri, Jul 12, 2013 at 1:40 PM, Elliott Sprehn <espr...@chromium.org>wrote: > Can we just add a new event that takes an event object instead of a huge > list of arguments? :) > > > On Fri, Jul 12, 2013 at 11:30 AM, James Greene > <james.m.gre...@gmail.com>wrote: > >> I'd rather get an Error-like duck-typed object with this shell info for >> cross-domain requests than to not get a real Error object when the >> unhandled error *is* from the same origin. >> >> Adding the trace as another new argument to `window.onerror` is certainly >> an option but the parameter list is getting long and I suspect that Error >> prototypes may still gain additional properties in the future. Continuing >> down this path of adding more parameters rather than just passing an Error >> instance or Error-like object (or providing a separate supplemental method >> like `window.getLastError()` seems like one of those decisions that might >> results in infinite sadness in the future. >> >> Sincerely, >> James Greene >> >> >> >> On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters <sim...@opera.com> wrote: >> >>> On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn <espr...@chromium.org> >>> wrote: >>> >>> On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt <oli...@apple.com> wrote: >>>> >>>> ... >>>>> That's tricky - what is your "stack trace"? You can very easily end up >>>>> leaking private information across frames. >>>>> >>>>> >>>>> window.onerror is triggered across non-same origin frames? >>>> >>> >>> Yes, but always with these arguments: >>> >>> "Script error.", "", 0, 0 >>> >>> -- >>> Simon Pieters >>> Opera Software >>> >> >> >