i18n API - Invalid option values should not throw
Marcos Caceres
ecmascript at marcosc.com
Wed Sep 5 18:53:12 PDT 2012
Hi Norbert,
On Thursday, 6 September 2012 at 00:04, Norbert Lindenberg wrote:
> Hi Marcos,
>
> I have a few more comments on your comments below, but here's the main important reason for exceptions: They are the prerequisite for compatibly introducing new values over time.
>
> The issue is: If we assign a default behavior to values that aren't explicitly described in the spec, then applications may come to depend on this default behavior. There've been many cases in the past where TC 39 couldn't introduce new behavior because there was an established behavior for a construct and the concern that applications depended on it. The case where TC 39 generally agrees that behavior can be changed is when the current behavior (both specified and implemented) is to throw an exception.
>
> For example, we recently decided to introduce new Unicode character escape sequence of the form \u{xxxxxx} into the language for ES6. For identifiers and string literals, there was no compatibility concern, because in both cases the ES5 specification required to throw exceptions for such character sequences, and implementations followed the spec. For regular expression literals, even though the specification required to throw an exception, implementations had consistently assigned a different meaning to such character sequences (/\u{10}/ is interpreted as /u{10}/). TC 39 therefore decided that the new Unicode character escape sequences could be supported in regular expression literals only under a new flag.
>
> In addition, it doesn't seem that the Internationalization API is alone in using exceptions. WebIDL provides enumeration types, defined as sets of strings just like we use them, and in its ECMAScript binding specifies that unknown strings result in a TypeError exception (slightly different from the RangeError exceptions we use). An enumeration is used, for example, in the TextTrack API within HTML5.
> http://www.w3.org/TR/WebIDL/#idl-enums
> http://www.w3.org/TR/WebIDL/#es-enumeration
> http://dev.w3.org/html5/spec/single-page.html#texttrackmode
Thank you for the clarification - you are correct. Although I don't personally agree with currently specified behaviour, I can understand the rationale given above for the current design.
Kind regards, and again, great work on the spec! :)
Marcos
--
Marcos Caceres
http://datadriven.com.au
More information about the es-discuss
mailing list