On Monday, September 26, 2011 2:36 AM Anne van Kesteren wrote:
> On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren
> <ann...@opera.com>
> wrote:
> > On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio
> > <isra...@microsoft.com> wrote:
> >> This is our understanding on how the spec needs to change to support
> >> the new WebIDL exception handling model. We would start by removing
> >> all of the constants from IDBDatabaseException. After that, the only
> >> thing left would be message. Do we still need to have this class
> >> definition? It seems we can remove it.
> >>
> >> In either case, we would have to continue by defining a set of
> >> exception types and code mappings. Each exception type will have a
> >> code value of 0.
> >>
> >> The mapping will look like this:
> >> UnknownError(0)
> >> NonTransientError(0)
> >> NotFoundError(0)
> >> ConstraintError(0)
> >> DataError(0)
> >> NotAllowedError(0)
> >> TransactionInactiveError(0)
> >> AbortError(0)
> >> ReadOnlyError(0)
> >> TimeoutError(0)
> >> QuotaError(0)
> >> VersionError(0)
> >>
> >> If we believe the message attribute is still relevant, then we would
> >> define the IDBDatabaseException class like this:
> >> exception IDBDatabaseException: DOMException {
> >> DOMString message;
> >> };
> >> Using this approach, IDBDatabaseException will inherit the name and
> >> code properties from DOMException.
> >>
> >> Is this what you had in mind?
> >
> > The new approach is outlined here:
> >
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c14
> >
> > I should probably update DOM4 with some easy to use language,
> > including how this maps to the code member.
>
> I've done that now.
>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
>
> If that is correct I would expect Indexed Database API to say e.g.
>
> "throw a VersionError exception" in its prose.
>
> We should probably keep these exceptions central somewhere so we do not
> mint similar exceptions twice. E.g. QuotaError looks like it could be the same
> as the existing QuoteExceededError.
>
> The table in DOM4 could be that central place I suppose as other than the
> code numbers it is largely non-normative so we could update it as editorial
> changes whenever we want.
>
> What do people think?
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
Like Cameron says in the link above and based on the WebIDL description, it
seems we want the IndexedDB text to say, for example:
Throws a DOMException of type " VersionError". (vs. Throw a VersionError
exception)
This assumes we don't have a need for an IDBDatabaseException. Still yet to be
decided on.
In addition, it seem that the names I outlined above match the expected naming
convention outlined in the link you specified. However, we shouldn't redefine
any types which are already included in the DOM 4 exceptions section. We
should just use them and point to them.
For IndexedDB, we will include the following database specific exceptions in
our spec:
UnknownError
NonTransientError
ConstraintError
DataError
NotAllowedError
TransactionInactiveError
ReadOnlyError
VersionError
All of these exceptions will have a code of 0.
In addition, we would reuse the following types from the DOM 4 Exception
section:
NotFoundError
AbortError
TimeoutError
QuotaExceededError
While I can see the benefits of having an all-encompassing list of exceptions
people can go to see the various types, it seems that this could grow very
large and we'll see may exceptions which are not applicable to other
technologies. To that effect, we prefer all new feature specific exceptions to
be included in the spec they are used instead of a centralized table.
Israel
