On Sunday, 25 March 2012 at 03:16, Cameron McCormack wrote:
> Marcos Caceres:
> > Right. But it's as close as I can get to the real thing… so again we
> > come full circle about having some means of create a DOMException (or
> > if faking it is good enough, which may just be).
>
>
> Currently the requirements for platform exception objects are the same
> as for other platform objects. You can't for example create a Node
> object yourself in JS and have it work with the browser's DOM
> implementation.
Right. Without getting too academic here, that kinda sucks as an "interface" is not really an "interface" (in the classical black-box sense); this split in the platform between Platform objects and other objects kinda sucks… but such is life. Hopefully something we can address in the future.
> Good enough for what is the question, I guess. Given
> DOMException is defined like
>
> exception DOMException {
> // ...
> short code;
> };
>
> you cannot create a JS object with say
> Object.create(DOMException.prototype) and be able to access the code
> property on it, because the getter and setter functions will be defined
> to check if the object they're called on is a real platform exception
> object of type DOMException. So accessing that property will throw a
> TypeError instead.
Yep. I guess the use case I had in mind would enter into the platform (as everything is interpreted as within user objects… it's mostly for prototyping things like this: http://specs.wacapps.net/accelerometer/implementation/Accelerometer.js).
> Also Object.prototype.toString.call(yourObject) will return "[object
> Object]" instead of "[object DOMException]".
>
> So I think we really browsers to implement the [Constructor] here. :)
Agreed… grumble:) Thanks for the clarifications!
I got this far based on our discussions:
http://jsfiddle.net/yDNgL/31/
Added it to this:
http://stackoverflow.com/questions/5136727/manually-artificially-throwing-a-domexception-with-javascript