Re: [DOM3Events] Exceptions

This change sounds good to me. I generally support simplifying and
consolidating the exceptions thrown. I'm strongly suspect we could change
the exceptions thrown in most cases without a hit to web compatibility.

On Sat, Mar 5, 2011 at 1:52 AM, Anne van Kesteren <annevk@opera.com> wrote:

> I removed EventException from DOM Core and I think that change makes sense.
> We use DOMException for most of our APIs. Only dispatchEvent() throws
> exceptions of this type and it seems like unneeded complexity to me.
>
> DOM Level 3 Events says dispatchEvent() can throw these exceptions:
> EventException.UNSPECIFIED_EVENT_TYPE_ERR,
> EventException.DISPATCH_REQUEST_ERR, DOMException.NOT_SUPPORTED_ERR, and
> DOMException.INVALID_CHARACTER_ERR.
>
> I have not been able to get implementations to throw any of the latter two
> exceptions. Examples would be most welcome.


WebKit does throw NOT_SUPPORTED_ERR in a number of cases (see
http://codesearch.google.com/codesearch?as_q=NOT_SUPPORTED_ERR&vert=chromium&as_lang=c%2B%2B&as_filename=WebKit).
I haven't looked at most of these to see if they are actually valid uses of
this exception or if the code can even be hit. It took some hunting but I
finally got it to fire in one case to fire in a real page,
http://plexode.com/eval3/#jt=document.createTreeWalker().


> In fact the text for INVALID_CHARACTER_ERR seems to overlap with
> UNSPECIFIED_EVENT_TYPE_ERR as they are both talking about restrictions on
> Event.type. However, what the restrictions on Event.type are is not at all
> clear. Event.type only says that no events should be created that contain
> whitespace. It does not say anything about the empty string, or whether
> initializing events with whitespace in their type will throw an error or not
> (either then or later).
>
> I do not think we need UNSPECIFIED_EVENT_TYPE_ERR at all really. Why should
> we require invoking initEvent()?
>

Indeed.


> And DISPATCH_REQUEST_ERR could easily be replaced by INVALID_STATE_ERR. We
> use it that way in tons of APIs.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>