preventExtensions trap and its true/false protocol

Tom Van Cutsem at
Mon Apr 1 08:22:27 PDT 2013

Hi David,

The messages you cite discuss the return value of the oddball
"unknownPrivateSymbol" trap.

For the preventExtensions trap I see no reason to be inconsistent with the
"set" and "defineProperty" traps.

Also, Reflect.preventExtensions (and Reflect.set, Reflect.defineProperty)
will make the boolean trap return value directly visible and usable.

Personally, I find code like:

if (Reflect.preventExtensions(obj)) {
  // success code
} else {
  // failure code

cleaner than:

try {
  // success code
} catch (e) {
  // failure code

Moreover, in the latter piece of code, we may accidentally catch the wrong

In short, I don't see what's wrong with the boolean return value protocol.
I find it much cleaner than the throw/return protocol. In addition, boolean
return values can be more easily combined using the boolean operators.
throw/return exit "signals" can't be combined that straightforwardly.


2013/4/1 David Bruant <bruant.d at>

> Le 31/03/2013 21:17, Jeff Walden a écrit :
>  On 03/31/2013 11:02 AM, David Bruant wrote:
>>>  From the developer perspective, this doesn't really add anything since
>>> it's already possible to throw from within the trap (and that's probably
>>> more explicit and clearer than returning false).
>> That puts the onus on the trap to throw the correct kind of error, right?
> What do you mean by "correct"? It's already possible to throw any sort of
> error from any trap; I'm not sure what's correct and what isn't in that
> context.
>  Admittedly this should be easy enough to get right, but it is a slight
>> bit of extra complexity, versus having the implementation throw the correct
>> error in one central location.
> I think the difference is at best marginal.
> As a reader of people writing JS code, I'd rather have people explicitly
> throwing than having to remember which trap has a true/false protocol.
> As a web developer, I'm happy if the surface of things to test for web
> browser implementors is smaller ;-) (and that's going to be a net reduction
> in terms of spec and I guess in implementations if the trap result is just
> ignored)
> David
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list