On Dec 12, 2012, at 10:52 AM, John J Barton wrote: > > > > On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock <[email protected]> > wrote: > > On Dec 12, 2012, at 10:23 AM, John J Barton wrote: > >> >> >> >> On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock <[email protected]> >> wrote: >> >> On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote: >> >>> All the Object functions that operate on multiple properties are currently >>> specified using pendingException which reports the first thrown exception >>> after going through all the properties. defineProperties, freeze, etc. >> >> In, ES6. This is a breaking (hopefully nothing) change from ES5 that was >> suggested by Mark Miller. >> >> The desire is to decrease the non-determinism that an early throw >> introduces. >> >> How can multiple calls to Object.mixin with identical state result in >> different results? > > Because the order that the source properties are visited is unspecified. It > can differ among implementations and in theory could even differ within a > single implementation. > >> >> In the ES6 approach all property updates that can occur will occur, before >> the exception is thrown instead of leaving the object in a less well defined >> partially updated state. >> >> If an exception is thrown because of an error in Object.mixin, what state is >> the object in? Will the spec define that state? > > Yes, all property additions (to the target object) that can complete will > complete. > > And I assume then that the exception thrown will be 1) standardized, 2) > specify the properties that are undefined on the target as a result of > exceptions, and 3) provide those exceptions. That seems to be what we need > to have any chance to use this feature. >
It is currently specified as a whatever exception is first thrown by an operation upon an individual property. Those exceptions are specified at a more primitive level. In general, the ES spec doesn't specify anything about thrown exception other than which specific exception "class" to throw. It does not specify a message or any other added payload. I'm not sure that there is an actual utilitarian use cause for this behavior. It is more about minimizing non-determinism that might impact interoperability among implementations. How would throwing early versus throwing late make any different to you? Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
