W3C home > Mailing lists > Public > www-svg@w3.org > April 2012

Re: replacing SVGException with new style Web IDL exceptions

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 9 Apr 2012 21:05:09 -0700
Message-ID: <CAGN7qDDjDYjB8b69hhgSs4nQrgdQFmqmgFd_ekL6kwJdQrgm6Q@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: SVG public list <www-svg@w3.org>
Will this cause issue with backward compatibility?
If so, can we define it so that the exceptions implement both interfaces?


On Mon, Apr 9, 2012 at 6:42 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> We will need to have SVG 2 use new style Web IDL exceptions.  For
> DOMExceptions, the DOM Core spec already defines the relevant exception
> types, so we can just link to those.  I think we should get rid of
> SVGException seeing as it doesn't expose any exception members other than
> "code", just like DOMException.
> The only two codes of SVGException that are in use in the spec are
> suggestions for replacing them:
> * Where SVG_INVALID_VALUE_ERR is used for a malformed DOMString value,
>  such as operations like setPaint on SVGPaint (which we might not even
>  keep, given it's a DOM 2 Style thing) we should throw a SyntaxError.
> * Where SVG_INVALID_VALUE_ERR is used for an out of range integer
>  enumeration or float, like SVGMatrix.rotateFromVector, we should
>  throw a RangeError.
>  (SVGLocatable.**getTransformToElement and SVGMatrix.inverse), we should
>  throw a DOMException of type "InvalidStateError".
> I very much doubt anyone is relying on the specific code values or their
> being SVGException objects here.
Received on Tuesday, 10 April 2012 04:05:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:28 UTC