On Mon, Sep 26, 2011 at 5:40 PM, Israel Hilerio <isra...@microsoft.com> wrote:
> 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.
>From my understanding of the WebIDL spec, the idea is that
specifications like IndexedDB should throw exceptions which use the
DOMExceptions interface. The various errors would use different string
values for .name which would replace the current codes that we have
now. However, if existing ECMAScript errors can be used, we should use
those.
Cc'ing Cameron so that he can confirm that this is a correct understanding.
I *think* that this matches what you're saying above, but I wanted to
double-check.
> For IndexedDB, we will include the following database specific exceptions in
> our spec:
> UnknownError
> NonTransientError
> ConstraintError
> DataError
> NotAllowedError
> TransactionInactiveError
> ReadOnlyError
> VersionError
For several of these I think we can reuse existing DOMExceptions.
Here's how I'd map the exceptions which are currently in the IndexedDB
spec:
UNKNOWN_ERR
Mint a new UnknownError. Alternatively we could simply throw an
ECMAScript Error object with no more specific type.
NON_TRANSIENT_ERR
I think in many cases we should simply throw a TypeError here. That
seems to match closely to how TypeError is used by WebIDL now.
NOT_FOUND_ERR
Map to DOMException NotFoundError
CONSTRAINT_ERR
Mint a new ConstraintError.
DATA_ERR
This one is tricky. It feels like there *should* be an existing error
we can reuse, but none that I see really fits the bill. So maybe mint
a new DataError.
NOT_ALLOWED_ERR
Map to DOMException InvalidStateError
TRANSACTION_INACTIVE_ERR
Mint a new one here
ABORT_ERR
Map to DOMException AbortError
READ_ONLY_ERR
This is similar to DOMException NoModificationAllowedError. However
I'd say that it's different enough that we should mint a new
ReadOnlyError. It seems especially important for indexedDB to have a
descriptive error here as this is likely going to be a quite common
error to run into during development.
TIMEOUT_ERR
Map to DOMException TimeoutError
QUOTA_ERR
Map to DOMException QuotaExceededError
VERSION_ERR
Mint a new VersionError for this one.
Please do let me know if you disagree. It's tricky to know when it
makes sense to use a new more narrow error, vs reuse a broader
existing error.
I'll personally stay out of where to define the new errors. I'm happy
to have them in the IndexedDB spec, or to add them to the DOM4 spec.
/ Jonas
