- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 8 Sep 2010 11:01:44 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <aranganathan@mozilla.com>, public-webapps@w3.org
On Wed, Sep 8, 2010 at 12:43 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Wed, 08 Sep 2010 06:12:36 +0200, Arun Ranganathan > <aranganathan@mozilla.com> wrote: >> >> So I shall do as you did in the erstwhile Web SQL Database API. Perhaps I >> can keep the codes that I'm reusing from DOMException as is, so that they >> are consistent with DOMException (for greater developer familiarity). But >> in the future, additional exceptions that are File (or Blob) centric needn't >> keep pace with DOMException's exception codes. > > I would prefer if you either used consistent numbering or otherwise used > DOMException. We can design a new DOMError that follows the Web SQL Database > API conventions. After all, we are creating a new version of DOM Core. > > >> Which brings us back to having a dedicated exception and error interface >> for the File* APIs scenario, despite how attractive it is to have >> DOMException reused here. This allows specific codes that are File/Blob >> centric anyway. Cool? > > That works for me too, but then please use internally consistent numbering > rather than some codes matching DOMException and the new codes not matching > DOMException as that is just too confusing, especially going forward. I.e. > DOMException might gain a similar exception but it will have a different > number, so only for the older numbers it will match, etc. It just does not > make much sense. OK, so we stick with the current interfaces, but try to keep the numbers all matching/nonconflicting. Works for me.
Received on Wednesday, 8 September 2010 18:02:31 UTC