On Mon, Nov 14, 2011 at 6:45 PM, Michael Nordman <[email protected]> wrote: > I sure hope specific exception messages are not getting codified in specs.
Many folks in the web standards community would disagree. For example, the DOM4 effort is specifying these sorts of things: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception Many years of fighting web compatibility have taught us the browsers need to interoperate precisely, even in error conditions, or else silos of content will calcify around browsers that are wildly used in different market segments. The prevailing direction in the web platform today is to specify precise error handling behavior. That pendulum may well swing back towards fuzzy specs, but I somehow doubt WebSQLDatabase will be the vanguard of that reversal. > I don't see where the discussion of other browsers is relevant becaus it's > pretty clear other impls of this component aren't going to happen, yet this > remains a useful feature of webkit/chrome for the time being. It has issues > and i'd like to make it more useful. I wouldn't be too sure of that. If mobile sites persist in using WebSQLDatabase and other rendering engines want to enter the mobile market, those browser vendors will face a decision to either be at a competitive disadvantage (i.e., not support WebSQLDatabse) or to swallow their pride (i.e., implement WebSQLDatabase). History suggests which path they'll take. >From the perspective of the WebKit project, however, we don't want to make it any harder for other browser vendors to implement WebSQLDatabase, which means keeping proprietary extensions to a minimum. Of course, the ideal outcome is for these mobile sites to move away from WebSQLDatabse and to IndexedDB. > Afaict, the "platform" does define a means of expressing exceptional > conditions including a means of conveying a message that ideally provides > useful information. I'm not sure what I should read into your putting the word platform in quotation marks. My initial read is that you're mocking the web as a platform for applications, but I presume you meant to communicate something else. > I'd like to fill in that useful information part, I understand that. I'm suggesting that doing so isn't the best thing for the web platform. > "INVALID_STATE_ERR: DOM Exception 11" isn't particularly useful to anyone. > Its fair to say INVALID_STATE for many distinct low level error conditions, > there's nothing wrong with the API. My intent in starting this thread was to > determine the best way of providing a more detailed message. I don't agree > that "error messages are evil"? No one said anything about evil. They just create a testing, maintenance, and interoperability burden. Given that we'd prefer that fewer people used WebSQLDatabase (given that the other browser vendors have refused to implement it), the benefits of adding this functionality seem outweighed by the costs. > In the case of websql or indexedDB, where > there is a complex backing store of some kind that's likely different across > browsers, i think it is helpful to surface useful implementation specific > details for diagnostic and debugging purposes. Adding this feature would be a short-term benefit to some number of people. However, there is a long term cost that we need to consider as well. Adam > On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth <[email protected]> wrote: >> >> On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman <[email protected]> >> wrote: >> > 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. >> >> The cost of exposing detailed error information is that all browsers >> that implement WebSQLDatabase will need to generate the exact same >> errors in the exact same situations. Part of the reason why other >> browser vendors shot down WebSQLDatabase was that it was too reliant >> on implementation details of SQLite. Exposing these ad-hoc error >> states as part of the platform just makes that problem worse, >> especially if you're talking about a large number of error conditions, >> as you seem to be. >> >> > 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. >> >> The issue isn't the best way of implementing this feature, the issue >> is whether we should be exposing this level of implementation detail >> to the platform. If we can't abstract the error conditions into a >> small, finite list, there's very unlikely we'll be able to maintain >> precisely the same error behavior over time, let alone specify the >> behavior in sufficient detail and correctness that someone else could >> implement it precisely the same way. >> >> 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
