- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 29 Nov 2012 03:35:21 +0000 (UTC)
- To: James Greene <james.m.greene@gmail.com>, Simon Pieters <simonp@opera.com>
- Cc: whatwg@whatwg.org
On Tue, 8 May 2012, James Greene wrote: > > The problem [with window.onerror is] that this mechanism does not allow > us to inspect the pertinent Error object at all: it only provides us > with three arguments at invocation time: message (string), fileName > (string), and lineNumber (number). These are rarely useful in practice. Could you elaborate on what the exception object (Error or DOMException or whatever) provides that the onerror callback's arguments don't, that you would find useful for debugging? Is it just the stack trace? On Wed, 9 May 2012, Simon Pieters wrote: > > > > ## My proposal(s) to fix it > > As such, I propose the following two options as fixes: > > 1. Add a function like `getLastError` to the global `window` object that > > would fetch the actual `Error` object associated with the most recent > > unhandled error. I would foresee common usage looking something like the > > following: > > ``` > > var oldOnError = window.onerror; > > window.onerror = function myErrorHandler(errorMsg, url, lineNumber) { > > if (oldOnError) { > > return oldOnError(errorMsg, url, lineNumber); > > } > > var e = window.getLastError(); > > alert("Globally unhandled error! But we now can discover its origin. > > Details: " + e); > > return false; > > } > > ``` > > 2. Alternatively (though less preferably), we could also update the > > invocation arguments of `window.onerror` callbacks to include a new fourth > > argument that would be the relevant `Error` object itself: > > ``` > > var oldOnError = window.onerror; > > window.onerror = function myErrorHandler(errorMsg, url, lineNumber, e) { > > if (oldOnError) { > > return oldOnError(errorMsg, url, lineNumber, e); > > } > > alert("Globally unhandled error! But we now can discover its origin. > > Details: " + e); > > return false; > > } > > ``` > > While this essentially makes the first three arguments useless, I have > > posed it this way for the sake of backward compatibility. > > I'd prefer this second option (except making it the fifth argument), > because the exception object can become garbage earlier and because for > cross-origin script errors, the arguments to window.onerror are masked > for security reasons, and we would need to mask the exception object as > well, so it seems better to use the same mechanism for that. I don't really understand the practical difference between these two options, assuming getLastError() only returns a value while the onerror handler is being invoked. (If it returns a value after it's invoked, you get the problem zcorpan describes above, of the value not being garbage collectable until much later.) > Also for compile script errors, there is no exception object. That's a good point also. On Fri, 11 May 2012, James Greene wrote: > > I personally am interested in adding the stack trace, yes, but ideally I > would just have access to the full "Error" object so I can always have > an up-to-date model if the "Error" object continues to change (as it > probably will). For example, some devs may be interested in the "Error" > object's "name" property, which is already a part of the object today > but is not provided to "window.onerror" callbacks. And again, if > additional properties are added in the future, it's just more and more > properties that may need to get incrementally added to the > "window.onerror" invocation arguments list. Having the exception object, if any, in the onerror callback, seems reasonable, and would indeed limit how many more arguments we may have to add over the years. It seems that providing it as an argument would be better than as a global, though. > For example, I proposed the addition of an "innerError" property (or > some would call it "cause") for chaining errors and masking internal > errors that consumers shouldn't see, instead providing a customer-facing > message. I'm not familiar with that proposal. On Fri, 11 May 2012, James Greene wrote: > > Alright... so what's next? I'm assuming this needs further discussion > with other WHATWG members chiming in. If I can help, please let me > know. I'd like to see this request through. Discussion isn't really what's needed, so much as commitments (or at least, positive interest) from browser vendors. See this FAQ entry: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F In general, providing the exception object as a fifth argument to onerror seems reasonable to me. Any implementors interested in adding this? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 29 November 2012 04:01:34 UTC