By "type" you mean "name" right?

Hi Travis, 

No, "type".  The spec says:
"Exceptions also have an associated type, also a DOMString, which is exposed on an exception object in a language binding-specific manner. The type of an exception is intended to be used to distinguish between the different kinds of exceptions that can be represented by the given IDL exception."

...and under 4.9.2 (the ECMAScript binding), we have:

Note

If an exception is thrown with a specific type, then the rules in section 4.11 below will create a shadowing “name” property on the exception object itself.

So, for ECMAScript, type == "name".

At least, that's how I read it :-)

Hi Travis,
Ok, I see where I am getting confused between type and name:

For clarity, Error.name is: 
http://es5.github.com/#x15.11.4.2

The key part that is confusing is that: "Exceptions also have an associated type, also a DOMString, which is exposed on an exception object in a language binding-specific manner". 

But then I expected a type attribute... which is the name:

There must be a property named “name” on the exception interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the identifier of the exception.

Note
If an exception is thrown with a specific type, then the rules in section 4.11 below will create a shadowing “name” property on the exception object itself.

(In reply to comment #3)
> ...and under 4.9.2 (the ECMAScript binding), we have:
> 
> Note
> 
> If an exception is thrown with a specific type, then the rules in section 4.11
> below will create a shadowing “name” property on the exception object itself.
> 
> So, for ECMAScript, type == "name".
> 
> At least, that's how I read it :-)

Though in our planned implementation, we're making the "name" property an
accessor on the exception prototype object _exclusively_ rather than creating
the shadowed property on the instance. It's less like ECMAScript's native
Errors, but allows webdevs to hook the "name" property for tracking much easier
(across all DOM-thrown exceptions), and was self-consistent with how we had
implemented DOMException's "code" property in the past. (Run-time addition of properties onto a thrown exception object was vetoed by my developers.)

We are also adding a stringifier.

Ok, so my conclusion is, all the right bits are in the spec, they are a bit dispersed. What would be really nice is if the spec could algorithmically and systematically "implement" an object (it tries to do this already, but it's not cohesive which gets really confusing). So ideally, parts of the spec could be written more like: 

 1. Make the  Interface object. 
 2. check the Extended Attributes (and expose if needed in global scope), 
 3. add the default stuff (name and message)
 4. Then add the members.

etc. 

Again, please take a look at ECMAScript5... it's pretty idiot proof in the way it's done (which means people like me can implement happily and rapidly). I'm finding that as I read WebIDL I'm having to go to the browser and do blackbox testing to understand stuff... I don't think I should have to be doing that (it defeats the purpose of the spec).

(In reply to comment #5)
> (In reply to comment #3)
> > ...and under 4.9.2 (the ECMAScript binding), we have:
> > 
> > Note
> > 
> > If an exception is thrown with a specific type, then the rules in section 4.11
> > below will create a shadowing “name” property on the exception object itself.
> > 
> > So, for ECMAScript, type == "name".
> > 
> > At least, that's how I read it :-)
> 
> Though in our planned implementation, we're making the "name" property an
> accessor on the exception prototype object _exclusively_ rather than creating
> the shadowed property on the instance. It's less like ECMAScript's native
> Errors, but allows webdevs to hook the "name" property for tracking much easier
> (across all DOM-thrown exceptions), and was self-consistent with how we had
> implemented DOMException's "code" property in the past. (Run-time addition of
> properties onto a thrown exception object was vetoed by my developers.)

nice :) 

> We are also adding a stringifier.

Sounds pretty cool.

The structure of the spec, generally, is that section 3 describes IDL, independent of language bindings, and section 4 describes how IDL constructs correspond to things in an ECMAScript environment.  So you would read #idl-exceptions to see what they are in IDL, and what author conformance criteria there are.  Then you would read the sections related to exceptions in section 4 (4.9, 4.10 and 4.11) to see what ECMAScript implementation requirements there are.

Note that you can click on the defining instance of the term "type" in #idl-exceptions and it will show you where that term is referenced in the rest of the spec.

I used the term "type" here because I thought "name" would sound more like the identifier of the exception, and for DOMExceptions those two things are not the same.

Marcos, if you have any specific suggestions for changes to the spec please make them.

Travis, do you think the spec should change wrt the name property?  How does your stringifier differ from the one inherited from Error.prototype?

Hi Cam, 
I'll try my best to suggest some text once I'm sure I've implemented the whole exception section. Sorry if I'm a bit schizophrenic while I'm implementing (please bear with me, even if most of the bugs turn out to be nothing). I'll keep reporting bugs as a I go, if only as a way of tracing where I got confused or ran into problems... so, although they may not be "technical" bugs, they might be structural bugs in the spec. 

is that ok? Otherwise, I can gather thoughts elsewhere and email them to you. Let me know what works best.

Either way, but concrete suggestions are easier for me to deal with. :)

(In reply to comment #8)
> Travis, do you think the spec should change wrt the name property?  How does
> your stringifier differ from the one inherited from Error.prototype?

I'd like it to change, but I wouldn't block CR for it. The planned
implementation only gets IE part-way there; exceptions won't inherit from
Error.prototype, for example--which is why we had to add the stringifier :-( )

OK, so no stringifier changes would be needed in the spec.  I think I still prefer how the way the name property behaves like built in JS Errors, so I will leave that for now.

Resolving NEEDSINFO to await concrete suggestions of spec clarifications for the original issue.