http://trac.webkit.org/browser/trunk/LayoutTests/js/script-tests/class-syntax-super.js#L59 shouldThrow('new (class extends null { constructor() { super(); return undefined } })', '"TypeError: undefined is not an object (evaluating \'super()\')"'); and http://trac.webkit.org/browser/trunk/LayoutTests/js/script-tests/class-syntax-super.js#L64 shouldThrow('new (class extends null { constructor() { super() } })', '"TypeError: undefined is not an object (evaluating \'super()\')"'); The reason super() throws is because Function.prototype is not constructable. Your test seems to be testing the return value. It should never get there.
Oh, this is because of the way I'm retriecving Function.prototype. It is in fact throwing up before calling super() so our behavior is corect. Thanks for filing all these bugs :)
It is not clear to me that you are throwing at the right spot: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-super-keyword-runtime-semantics-evaluation You should throw in step 7/8 in SuperCall : super Arguments In this case there is no undefined value.
Yes, that's what's happening (throw in step 7 of 8) You're right that the error message isn't exactly descriptive/informative but I don't feel like I need to improve it since it's such an edge case. Or do you feel that web devs will end up hitting this error often?
> Or do you feel that web devs will end up hitting this error often? I don't think this is a common case but the current message is pretty confusing. I assume it is hard coded so you can easily change it?
No, the problem is that I'm relying on accessing undefined to throw an exception in this case right now, and I'd need to add a runtime branch if I wanted to throw a nicer error message here.