W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: Constructible Exceptions

From: Marcos Caceres <w3c@marcosc.com>
Date: Sun, 25 Mar 2012 00:32:10 +0000
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-script-coord <public-script-coord@w3.org>
Message-ID: <5EBEB8A13E7B404EA7E09DD765CDFC15@marcosc.com>



On Saturday, 24 March 2012 at 00:56, Cameron McCormack wrote:

> Marcos Caceres:
> > The use case for throwing custom WebIDL exceptions is to be able to
> > implement WebIDL interfaces directly in JavaScript (when allowed by
> > the presence of [Constructor])…. though my real use case is to be
> > able to construct DOMExceptions in JS, I'll need to take that up with
> > DOM4.
>  
> This is already possible, because exception interface objects are  
> required to be function objects with a [[Call]] behaviour that  
> constructs the exception. So there is no need for [Constructor] on them.

Yeah.. I kinda realised that after I sent the email… however…. how do you create one without first coercing an exception object out of the exception type you want? I had a go at trying to do it [1]… but I had to do the following for a DOMException:

try {
        //force an exception to be generated;  
        document.removeChild({})
 } catch (e) {
        //use it as the prototype   
     newException = Object.create(e)
}


//alias for the prototype, helps us populate the new object
var proto = newException.__proto__

//"shadow" the name property on the new object  
//Chrome claims these are writable, but they aint! :)  
props = Object.getOwnPropertyDescriptor(proto, "name");
props.value = name;
Object.defineProperty(newException, "name", props);


… And so on…   

Kind regards,
Marcos  

[1] http://jsfiddle.net/yDNgL/30/
Received on Sunday, 25 March 2012 00:32:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC