866788 - WebIDL generated errors don't have any stack trace

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Julien Wajsberg [:julienw]]

see http://everlong.org/mozilla/testcase-webidl-errors/ for a testcase

We can see that normal errors have a stack, but webidl-generated errors have an empty error.stack property.

This is desirable for Gaia work because the stack trace shows up in Mocha outputs, that we use for unit testing.

Comment 1

[Boris Zbarsky [:bzbarsky]]

That's not a WebIDL error for what it's worth.  That's a DOMException.  See bug 857648.

A WebIDL-generated error would be more like if you replaced removeChild(elt) with removeChild("abc") and has the stack you want.

That said, it may be useful to transition to throwing actual JS Errors instead of DOMExceptions for the things like INDEX_SIZE_ERR, NOT_FOUND_ERR, etc...  We really need to fix our general exception story to follow the spec better here, but I can't quite understand what the spec is actually saying should happen.  Anne, Cameron, should removeChild be throwing an Error, or some subclass (in the ES6 sense) of Error, or a DOMError, or something else?

Julien, this might need to be fixed on a case by case basis, modulo whatever happens in bug 857648...

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://dev.w3.org/2006/webapi/WebIDL/#es-exception-interface-prototype-object

> The exception interface prototype object for a given exception MUST
> have an internal [[Prototype]] property whose value is as follows:
>
> ... The value of the internal [[Prototype]] property is the Error
> prototype object ([ECMA-262], section 15.11.3.1).

Comment 3

[Julien Wajsberg [:julienw]]

Boris> oki, that's because I started to see such stackless errors when we transitioned to WebIDL.

Thanks to all.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  When we transitioned nodes to webidl?

I thought the mechanism we used for throwing the "not found" exception here was the same for WebIDL and XPConnect...

Comment 5

[Masatoshi Kimura [:emk]]

The spec doesn't define .stack in the first place. Neither ES6 draft nor the JaavScript Standard <http://javascript.spec.whatwg.org/> defines the property. It's a de-facto standard atm.

Comment 6

[Anne (:annevk)]

The latest plan is to centralize all exception handling in IDL directly: http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html Seems Ms2ger answered the other question.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> because I started to see such stackless errors when we transitioned to WebIDL.

Julien, I'm still trying to pin down what you meant here.

I tried your testcase in Firefox 18 (which has no nodes on WebIDL bindings) and Firefox 4 (which has no WebIDL anything anywhere) and in both cases the exception produced by the document.body.removeChild call has no "stack" property at all (as in, e.stack is "undefined" and |"stack" in e| tests false).

The same continues to be true in today's nightly.

So what exactly changed with WebIDL here?

Comment 8

[Julien Wajsberg [:julienw]]

I think I jumped a little to fast to this conclusion because it looked the same than another error I had. So sorry about that.

I changed my testcase to add the actual error I've seen before. The IDL error happens only in builds with WebIDL (so there is no error in Firefox older than v21). And... I see a stack trace in all builds that have WebIDL.

So I think we can close this invalid until I see something new.

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK, sounds good.  ;)