preventExtensions trap and its true/false protocol
bruant.d at gmail.com
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
> 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