Closed Bug 978232 Opened 6 years ago Closed 5 years ago

ES6 Proxies: [[Construct]] hook doesn't throw if handler hook doesn't return an object.

Categories

(Core :: JavaScript: Standard Library, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: efaust, Assigned: efaust)

References

Details

(Whiteboard: [js:p1])

Attachments

(2 files, 1 obsolete file)

This is trivial. We just have to do it.
Attached file Trivial test case.
A simple test case that should throw, but doesn't
Component: JavaScript Engine → JavaScript: Standard Library
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [js:p1]
Fix with test
Attachment #8386440 - Flags: review?(jorendorff)
Assignee: nobody → efaustbmo
Status: NEW → ASSIGNED
Missed out on updating a test
Attachment #8386440 - Attachment is obsolete: true
Attachment #8386440 - Flags: review?(jorendorff)
Attachment #8387151 - Flags: review?(jorendorff)
Comment on attachment 8387151 [details] [diff] [review]
Throw if the trap return value is not an object

Review of attachment 8387151 [details] [diff] [review]:
-----------------------------------------------------------------

Swiped, given offhand mention on IRC that I should feel free to take a look at this.

The error message might be kind of internal-ish reading, but I'm not inclined to wordsmith too hard right now.

::: js/src/tests/ecma_6/Proxy/proxy-constructNonObject.js
@@ +1,1 @@
> +function bogusConstruct(target) { return 4; }

Add a second one:

function bogusConstruct(target) {}

and test that as well.  The |handler.construct| invoked during construction, is invoked by calling it.  So this method returns |undefined|, a primitive, and construction should fail.

@@ +1,3 @@
> +function bogusConstruct(target) { return 4; }
> +
> +var handler = { construct: bogusConstruct }

Trailing semicolon?  Do not want ASI.

@@ +12,5 @@
> +} catch(e) {
> +    threw = true
> +}
> +
> +reportCompare(threw, true, "[[Construct]] must throw if an object is not returned");

Use assertEq, and add

if (typeof reportCompare === "function")
  reportCompare(true, true);

at the end.  assertEq's arguments order actual/expected in that order, but reportCompare inverts them, and nobody expects that ordering.  (Plus this makes the test runnable standalone, without spinning up the whole jstests harness monstrosity.)
Attachment #8387151 - Flags: review?(jorendorff) → review+
https://hg.mozilla.org/mozilla-central/rev/037edc1bb501
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.