Re: Should Exceptions be Errors in the ECMAScript bindings?

On Jun 21, 2012, at 11:43 PM, Cameron McCormack wrote:

> Allen Wirfs-Brock:
>> In ECMAScript, prototype chain inheritance does not establish a deep semantic "is-a" relationship. In particular,
>>      var foo=Object.create(Error.prototype)
>> does not give foo any special Error object internal semantic state or behavior (eg, implementation specific stack trace semantics).
> 
> What would be required to make exception objects be true Error objects?  Is it sufficient to have Web IDL just say that they have [[Class]] "Error"?  Do Error objects have any standardised behaviour that you wouldn't get from just using prototype inheritance as Web IDL currently does?
> 

It seems  (I need to research this a bit more to be sure) like what should work  is to simply define your exception objects just like the ES spec defines "NativeError" objects[1].  The NativeErrors are all essentially "subclasses" of Error of the exactly the sort you will get with the proposed ES6 class extensions if you said [2]:
  class DOMException extends Error.prototype {
      constructor(...args) {super(...args}
  }

You can wire up essentially the same structure manually which is what the ES5 spec. does for the NativeErrors.

Note that while there isn't currently any  special standardized behavior for Error, implementations do have non-standard behaviors such as capturing stack traces.  This would have to be dealt with in the actual implementations but conceptually is captured by the super constructor call. 

Allen

[1] http://ecma-international.org/ecma-262/5.1/#sec-15.11.7 
[2] there is a subtle reason why I had to say "extends Error.prototype" rather than "extends Error".