On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.
I could certainly introduce a DOMError interface with a name and a message
attribute. For the APIs that want to provide the same information
asynchronous as they do synchronous through exceptions that makes sense.
Would that work?
OK. So it's when we need new exception codes, names, and types that the
confusion with this model sets in. While we can add to DOMException in
a decentralized way, do the editors of DOM4 intend to add the new
exceptions to DOMException?
I'll leave this one for Anne. I personally don't care where the new
strings are defined. Anne seemed to prefer to do it in the DOM4 (aka
DOM Core) spec, but I don't think we want to block on that happening.
The idea I had was that everyone can introduce new strings. After all, as
far as normative statements in a specification go, you need nothing more
than this line:
# Throw a "SyntaxError" exception
On top of that my plan was that whenever a specification author introduces
a string there that is not yet in DOM4 they send a request for it to be
included and one of the DOM4 editors will add the exception and a brief
description to the overview table. Having it in the overview table will
help other editors choosing the appropriate string. Apart from making sure
certain strings get their legacy code value assigned (already in the
table) the table would be completely non-normative however and no
specification introducing strings not yet in the table is blocked by it
updating. It's just an overview.
--
Anne van Kesteren
http://annevankesteren.nl/
