ES3.1-strict spec bug & proposed fix: method calls on primitives.

Mark S. Miller erights at
Thu Jan 8 21:27:10 PST 2009

On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich <brendan at> wrote:

> [lots of agreement]


> Generic programming with primtiives more often wants to *read* undefined
> when getting a non-existent property, and "object detect" without having to
> try/catch. This common use case is not served by strict mode in ES3.1,
> right? You'd have to change code to try/catch around such probes.

ES3.1-strict and nonstrict both return undefined from a failed read for
exactly this reason, as does Caja. The feature testing pattern is pervasive
and we dared not break it. The rationale is that a failed read is *not*
silent n practice, and so is adequately non-hazardous for integrity. It
returns an undefined, which is likely to be noticed, since the operation in
question is, after all, a read.

This rationale does not apply to "delete" returning false, since in practice
much code calls delete, assumes success, and does not check the return
value. In the face of new user-defined non-configurable properties, failed
deletes will be more common, so this hazard becomes worse. So a failed
strict delete does throw. You do indeed have to place try/catches around
strict deletes to simulate their current behavior.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list