In IDL not being part of an enumeration throws TypeError. It seems
String.prototype.normalize uses RangeError. I've no preference as to
which is better, but it would be good if they were equal.
Also, throughout the platform we typically lowercase enumeration
constants, e.g. arraybuffer. I think
Hi Michael,
es-disc...@michael.ficarra.me writes:
Oh, sorry for the duplicate. It appears you guys were just recently
discussing this, though it failed to turn up in my searches.
The discussion only started on test262. If it's going to entice a spec
change, it's great to talk about it here.
(Sorry for the latency, but I only get internet access by tethering
here.)
bruan...@gmail.com writes:
Le 05/08/2013 17:08, Brendan Eich a écrit :
Michael Ficarra wrote:
specified that the global object's prototype chain must include
Object.prototype. I am sure there's plenty of code that
On Aug 6, 2013, at 7:59 AM, Anne van Kesteren wrote:
In IDL not being part of an enumeration throws TypeError. It seems
String.prototype.normalize uses RangeError. I've no preference as to
which is better, but it would be good if they were equal.
The argument to String.prototype.noralization
On Tue, Aug 6, 2013 at 4:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The argument to String.prototype.noralization is not an enumeration (not an
ES concept) but a string. If the agument can not be converted to a string
value, a TypeError is thrown. If the string value is not within
Right, I think both are indeed enums at some conceptual level. IDL gives that
concept a name; ES does not. It would be nice if IDL enums followed ES
semantics, of doing `ToString(value)` (which may throw a `TypeError`) and then
throwing a `RangeError` if outside the allowed range.
However, the
On Tue, Aug 6, 2013 at 11:50 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Right, I think both are indeed enums at some conceptual level. IDL gives
that concept a name; ES does not. It would be nice if IDL enums followed ES
semantics, of doing `ToString(value)` (which may throw a
On Aug 6, 2013, at 10:24 , Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Aug 6, 2013 at 11:50 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
However, the [definition of `RangeError`][1] probably needs some updating in
that case:
Indicates a numeric value has exceeded the
Problem is, TypeError for what Python calls ValueError, what JS
might call DomainError to go with RangeError, is lame. Allen, Rick,
I forget: have we discussed DomainError or ValueError?
/be
Anne van Kesteren wrote:
On Wed, Jul 17, 2013 at 7:10 PM, Jonas Sickingjo...@sicking.cc wrote:
Good
Is a DomainError the dual of a RangeError?
On Tue, Aug 6, 2013 at 11:51 AM, Brendan Eich bren...@mozilla.com wrote:
Problem is, TypeError for what Python calls ValueError, what JS might
call DomainError to go with RangeError, is lame. Allen, Rick, I forget:
have we discussed DomainError or
We did discuss this, as record in
https://bugs.ecmascript.org/show_bug.cgi?id=224 , and concluded that we it we
didn't want to add any new built-in exceptions. Of the existing exceptions ,
RangeError is closest in concept to what might be described as ValueError.
Allen
On Aug 6, 2013, at
Allen Wirfs-Brock wrote:
We did discuss this, as record in
https://bugs.ecmascript.org/show_bug.cgi?id=224 , and concluded that
we it we didn't want to add any new built-in exceptions. Of the
existing exceptions , RangeError is closest in concept to what might
be described as ValueError.
I actually had ValueError in the 2011-10-31 draft of ECMA-402; the TC39 meeting
on 2011-11-16 decided against that.
http://wiki.ecmascript.org/lib/exe/fetch.php?id=globalization%3Aspecification_draftscache=cachemedia=globalization:working_draft_ecmascript_globalization_api_2011-10-31.pdf
Correction: The November meeting didn't quite decide; there was more discussion
on es-discuss and at the TC39 meeting on 2012-01-19:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/thread.html#18685
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
Norbert
On
On Aug 6, 2013, at 12:40 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We did discuss this, as record in
https://bugs.ecmascript.org/show_bug.cgi?id=224 , and concluded that we it
we didn't want to add any new built-in exceptions. Of the existing
exceptions , RangeError is closest in
Even though I contributed the suggestion, I agree with Allen. It is already
way too late to pretend that JS is a language in which it is useful to
dispatch on the type of error. Given that, let's leave well enough alone
and not introduce more error types for any reason other than legacy compat
Allen Wirfs-Brock wrote:
On Aug 6, 2013, at 12:40 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We did discuss this, as record in
https://bugs.ecmascript.org/show_bug.cgi?id=224 , and concluded that we it we
didn't want to add any new built-in exceptions. Of the existing exceptions ,
On Tue, Aug 6, 2013 at 1:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Has anybody ever actually seen a JS exception handler that really needs to
take conditional action depending upon whether as TypeError or RangeError
was thrown?
For what it's worth, as someone using both promises
18 matches
Mail list logo
