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

Re: File API exception codes

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Tue, 7 Sep 2010 21:12:36 -0700 (PDT)
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps@w3.org
Message-ID: <1055613677.504824.1283919156557.JavaMail.root@cm-mail03.mozilla.org>
> On Tue, 7 Sep 2010, Arun Ranganathan wrote:
> >
> > It *does* seems sensible to use DOMException instead of
> > FileException in
> > the synchronous case (on WebWorkers). But in the asynchronous case,
> > DOMError seems a bit janky
> > (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces-DOMError).
> > So the DOMError exposes a DOMObject that is the affiliated
> > relatedException? That seems a bit harder than a mere FileError, but
> > I'm willing to go with DOMError here as well.
> >
> > I find what HTML5 does for adding exception codes pretty attractive.
> > And reusing DOMException and DOMError would alleviate the naming
> > issue
> > (BlobException/BlobError vs. FileException/FileError). I'm just
> > concerned that DOMError seems awkward -- is anyone working on it?
> 
> What I did in Web SQL Database is just have a SQLException interface
> for
> the sync case an an essentially identical SQLError interface for the
> async
> case, without any concern for keeping the numbers from clashing with
> DOMException (since they were on entirely different interfaces).
> 
> http://dev.w3.org/html5/webdatabase/#errors-and-exceptions
> 
> I agree that DOMError is a mess. We should probably assume it doesn't
> exist and start over, unless it's used anywhere.


OK, so that's why I have a FileException and a FileError; given that DOMError is a mess, I'd rather use something like FileError.  And given that we have a FileError, we ought to have a FileException for consistency (using DOMException and then using FileError would be weird).  

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.  

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?

-- A*
Received on Wednesday, 8 September 2010 04:13:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT