preventExtensions trap and its true/false protocol

David Bruant bruant.d at
Sun Mar 31 16:38:37 PDT 2013

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)


More information about the es-discuss mailing list