- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 23 Jun 2012 12:18:14 +1000
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Travis Leithead <Travis.Leithead@microsoft.com>, Erik Arvidsson <arv@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Allen Wirfs-Brock: > 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. OK. Although I don't use the same kind of wiring wording in Web IDL, it looks like the only requirement missing is that [[Class]] be "Error" (the {}.toString issue is solved as I mention in http://www.w3.org/mid/4FE52636.7050002@mcc.id.au). > 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. All right. Constructors for Web IDL exceptions do not explicitly invoke a superclass' constructor, but they do everything in http://es5.github.com/#x15.11.7.2 except set [[Class]] to "Error". It might be good to have a note to say that exception objects are intended to be errors, so any non-standard things that appear on Error objects like stack traces and line numbers should also appear on them.
Received on Saturday, 23 June 2012 02:18:53 UTC