On Wed, Aug 21, 2013 at 5:21 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
FWIW for non-DOM code I see people using `instanceof` much more often than
checking `name`.
In public-script-coord and elsewhere people have argued that
instanceof is an indication of badness:
On Tue, Aug 6, 2013 at 10:03 PM, Brendan Eich bren...@mozilla.com wrote:
That's not the issue. If you don't care about which (whatever the set of
standard error types), you might as well toss a coin. But clearly we have
some implicit rule or rules informing when to use RangeError vs. TypeError.
FWIW for non-DOM code I see people using `instanceof` much more often than
checking `name`.
Thus I personally think that creating a bunch of new `DOMException` subtypes
would be the way to go, e.g. a `PermissionDeniedError` whose `.name` is
`PermissionDeniedError` and whose `.__proto__` is
On Wed, Aug 21, 2013 at 12:21 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
FWIW for non-DOM code I see people using `instanceof` much more often than
checking `name`.
Thus I personally think that creating a bunch of new `DOMException` subtypes
would be the way to go, e.g. a
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
On Tue, Jul 16, 2013 at 5:05 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote:
Object.toString(x)
I assume you mean Object.prototype.toString.call(x)
I *don't* think it's important what this returns. I.e. I would guess
On Wed, Jul 10, 2013 at 11:49 PM, Mark S. Miller erig...@google.com wrote:
Hi Jonas,
The perpetual hazard with trying to clean things up is, of course, legacy
compat constraints. Regarding ES itself, many of those on this list
(including myself) feel oriented about when and where these bite
On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote:
Object.toString(x)
I assume you mean Object.prototype.toString.call(x)
I *don't* think it's important what this returns. I.e. I would guess
that we can safely subclass DOMException as needed.
I think we have the
Hi all,
What is the current expected way for an author to throw a custom
errors? You obviously could do something like:
throw { reason: TimeoutError };
or
throw TimeoutError;
However that makes it very hard for anyone receiving an exception to
inspect what it is. I.e. you'd first have to check
= Object.create(Error.prototype);
throw new SomeError('abc');
From: jo...@sicking.cc
Date: Wed, 10 Jul 2013 12:23:54 -0400
Subject: Creating your own errors
To: es-discuss@mozilla.org
Hi all,
What is the current expected way for an author
Woah, François, that seems pretty overcomplicated; why not replace everything
inside the constructor with `this.message = message`? It has the same effect in
the browsers I've seen. (Also don't forget `SomeError.prototype.constructor =
SomeError`.)
Anyway, to Jonas's point: I think `DOMError`
Hi Jonas,
As an example from the field, here is how we extend our own error types:
https://github.com/imvu/imvujs/blob/master/src/error.js
You can either switch on e.name or use e instanceof ErrorType in your catch
handler.
Like Francois's approach, it also preserves the 'stack' property if the
On Wed, Jul 10, 2013 at 12:52 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Woah, François, that seems pretty overcomplicated; why not replace everything
inside the constructor with `this.message = message`? It has the same effect
in the browsers I've seen. (Also don't forget
Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, such as callbacks. [1]
The DOM spec does however throw DOMException objects [2]. These are
instanceof Error (see WebIDL [3])
var ex;
try {
document.appendChild(document);
} catch (e) {
ex = e;
}
assert(ex
On Wed, Jul 10, 2013 at 3:49 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
In Blink DOMException also have a stack property
assert(stack in ex);
Since they are just Error objects
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
From: Jonas Sicking [jo...@sicking.cc]
Note that
```js
(new DOMError) instanceof Error;
```
returns false. So the DOM does do the strongly discouraged thing. Is this
ok or bad?
This is horrible! I had no idea! It should definitely derive from `Error`.
Also, the DOM does not create a
I am not sure where this conversation ended up so I hope I am not repeating
already said stuff but you can always create constructors that inherits
from Error and set the name.
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
// whenever you need
throw new CustomError;
```
At best, this will not preserve the stack trace property, at worse this will
lead to a bad one.
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
// whenever you need
throw new CustomError;
```
At best, this will not preserve the stack trace property, at worse this will
lead to a bad one.
Because the location info will
Because the location info will be that of the new Error? One could
try this instead, which seems to work for me:
throw { __proto__ : new Error(), reason: Monday }
That one seems to be working (except in IE11 since IE didn't support __proto__
prior to that). That somehow surprises me that
yep, I thought it was about having meaningful red errors with a proper name
in console. The stack can be addressed passing the `new CustomError
(new Error('message'))`
using error as argument, not big deal ... abusing __proto__ for this seems
like the wrong answer to a concrete problem
On Wed,
What's wrong with:
```javascript
throw new CustomError('message')
function CustomError(message /* accept any custom arguments here */) {
Error.call(this, message)
this.name = 'CustomError'
/**
* add any custom error info here
*/
}
CustomError.prototype = Object.create(Error)
wrong at least two things for the non ES6 version
1. `Error.call(this, message)` does not do what you think it should do
2. `CustomError.prototype = Object.create(Error)` has a typo, you meant `
Object.create(Error.prototype)`
In the ES6 version, I am not sure about constructors and classes,
On Jul 10, 2013, at 4:32 PM, Andrea Giammarchi wrote:
wrong at least two things for the non ES6 version
1. `Error.call(this, message)` does not do what you think it should do
2. `CustomError.prototype = Object.create(Error)` has a typo, you meant
`Object.create(Error.prototype)`
In
On Jul 10, 2013 3:49 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, such as callbacks. [1]
Indeed. But this is one of the things I'm trying to fix. It seems very
silly that the DOM defines two classes of error
oh well ... I've missed the part when you guys decided that inherited
defaults are useless as properties ... :-/
as you said, inconvenient, and not only this case ... also good to know ^_^
On Wed, Jul 10, 2013 at 4:56 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jul 10, 2013, at 4:32
35 matches
Mail list logo
