[whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'