W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: File API exception codes

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 8 Sep 2010 11:01:44 -0700
Message-ID: <AANLkTimwRbbedYgizyBAfYUd-_VEe612z263idoDffE-@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC