preventExtensions trap and its true/false protocol

David Bruant bruant.d at
Mon Apr 1 08:48:14 PDT 2013

Le 01/04/2013 17:22, Tom Van Cutsem a écrit :
> Hi David,
> The messages you cite discuss the return value of the oddball 
> "unknownPrivateSymbol" trap.
I assumed the comments applied to true/false protocols in general, but 
I'm interested if there is disagreement on that point.

> For the preventExtensions trap I see no reason to be inconsistent with 
> the "set" and "defineProperty" traps.
Historically, the internal operations these relate to needed to return a 
boolean and a decision on throwing or not was made based on strictness 
of the code. This isn't true for Object.preventExtensions.

> 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)) {
Note that Object.preventExtensions/seal/freeze do not return a boolean, 
but the object being manipulated. Is this an expected inconsistency? I 
hadn't given a lot of thoughts to it, but that could make a lot of sense.

>   // success code
> } else {
>   // failure code
> }
> cleaner than:
> try {
>   Object.preventExtensions(obj);
>   // success code
> } catch (e) {
>   // failure code
> }
> Moreover, in the latter piece of code, we may accidentally catch the 
> wrong exception.
That's what has been necessary to detect whether it was possible to 
freeze an host object or not (that is, detecting if it worked).
In any case, since an error can be thrown anyway from the trap (and the 
error won't be swallowed), doing a try/catch may still be necessary.


More information about the es-discuss mailing list