On Wed, Sep 8, 2010 at 12:43 AM, Anne van Kesteren <ann...@opera.com> wrote: > On Wed, 08 Sep 2010 06:12:36 +0200, Arun Ranganathan > <aranganat...@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.