On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth <[email protected]> wrote:
> For SQLException, there are a hundred exception codes reserved, > > static const int SQLExceptionOffset = 1000; > static const int SQLExceptionMax = 1099; > > of which, we appear to only be using eight. It sounds like you're > considering exposing more than a finite enumerated number of error > codes, however. Do we really want to make SQLite error messages part > of the web platform? What if we want to upgrade to a newer version of > SQLite in the future (which might have different error codes)? > IMHO, we shouldn't be investing much more effort into WebSQLDatabase. > It's something of a dead-end for the platform. If you're set on > investing more effort, one path forward is to figure out which are the > most important kinds of errors to distinguish and to give them error > codes. You can then give them descriptions as usual without needing > any custom bindings. > I don't want to change the set of exception 'codes' really. There are significant clients of WebSQL. They can't transition to IDB until it's up to the task and they've made that transition. For the time being, I'm willing to better support websql. There are a errors in the wild and figuring out what errors are "important" isn't as easy as it sounds. See http://code.google.com/p/chromium/issues/detail?id=98939 about "INVALID_STATE_ERR: DOM Exception 11". I'd like to be able to determine two things given the exception... callsite in webcore that failed and the sqlite error code seen at that callsite. That would make for a large number of new codes. If there's no general case for returning a custom message, a reasonable option for me may be to use [custom] bindings for these methods and to have that custom binding set the exception message attribute accordingly. > Adam > > > On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman <[email protected]> > wrote: > > I guess the exception of interest is SQLException. > > Take a look at Database.cpp line 103. The ' errorMessage' string on that > > line contains more detailed information about what went wrong in the act > of > > opening the database, including things like an sqlite error code and > sqlite > > error message. These strings are formed in the bowls of > > AbstractDatabase::performOpenAndVerify(). > > > > On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth <[email protected]> wrote: > >> > >> I'm not sure exactly what you're trying to do, but one option is to > >> add a new type of DOMException: > >> > >> > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in > >> > >> Another option is to customize the message from an existing exception > >> (here are the DOMCore exceptions): > >> > >> > >> > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp > >> > >> If you show me the spec you're trying to implement, I might have a > >> more concept suggestion of the best way to implement it. > >> > >> Adam > >> > >> > >> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman <[email protected]> > >> wrote: > >> > I have a case where given an IDL defined method thats defined to > raise a > >> > DOMException, I'd like to set a custom exception message from within > the > >> > webcore implementation and have that message percolate up into script > >> > via > >> > the bindings layer(s) and be accessible as the exception.message > >> > attribute. > >> > I don't see a non-custom way of doing that and am wondering if there > >> > should > >> > be support for something like this w/o having to resort to custom > >> > bindings? > >> > The particular methods I'm looking at are the openDatabase(...) method > >> > of > >> > DOMWindow and WorkerContext, but this seems like it might be useful in > >> > other > >> > cases as well. > >> > > >> > _______________________________________________ > >> > webkit-dev mailing list > >> > [email protected] > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > >> > > > > > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
