Re: [IndexedDB] Exceptions in IDB and the DOMException

Actually, I think we should abandon codes entirely and use the new
mechanism that WebIDL uses.

I honestly have a bit of a hard time understanding the WebIDL spec,
but I believe the idea is to implement the proposal made in [1].

Basically rather than having .code we'd have .type, along with
interface names for the various exceptions. If we did that then it
should be very easy to share not just identifier with DOMException,
but in fact use the exact same exception.

For what it's worth, DATA_CLONE_ERR is already a DOMException per spec.

I've been planning on filing bugs and start editing the spec to do
this once I dig through and understand the necessary WebIDL here.


/ Jonas

On Tue, Apr 19, 2011 at 11:13 PM, Pablo Castro
<> wrote:
> This came up today that I didn't remember having a conversation about it with folks.
> We currently have IDBDatabaseException with a some error codes as constants and code/message properties. Looking at DOMException as defined in DOM Core [1], it turns out that a) the pattern of the class is identica, but instead of code/message it has code/name and b) there are some errors present in both or that are very close (e.g. NOT_FOUND_ERR, DATA_CLONE_ERR, QUOTA_EXCEEDED_ERR).
> Would it be worth it trying to use the constants of DOMException when there's one already there that matches the need? If that was the case, would be it the constants that we would be reusing or would be have to throw a DOMException instead of an IDBDatabaseException?
> Separately, in reference to a) above, should we change IDBDatabaseException.message to for consistency?
> Thanks
> -pablo
> [1]

Received on Wednesday, 20 April 2011 22:06:00 UTC