- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Thu, 10 Feb 2011 07:30:24 +0000
- To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
- CC: ben turner <bent.mozilla@gmail.com>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
(back!) From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow Sent: Wednesday, February 09, 2011 6:47 PM >> On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow <jorlow@chromium.org> wrote: >> > On Wed, Feb 9, 2011 at 5:37 PM, ben turner <bent.mozilla@gmail.com> wrote: >> >> >> >> > Normal exceptions have error messages that are not consistient across >> >> > implementations and are not localized. What's the difference? >> >> >> >> These messages aren't part of any exception though, it's just some >> >> property on a transaction object. (None of our DOM exceptions, IDB or >> >> otherwise, have message properties btw, they're only converted to some >> >> message if they make it to the error console). >> >> >> >> > For stuff like internal errors, they seem especially important. >> >> >> >> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT >> >> code? >> > >> > I think that'd be ideal, yes. Since internal errors will be UA specific, >> > string matching wouldn't be so bad there. >> > If no one likes this idea, I'm happy hiding away the message in some >> > webkitAbortMessage attribute so it's super clear it's just us who implements >> > this. (Speaking of which, maybe you guys should do that with getAll.) >> We'll definitely put getAll under a vendor prefix once we drop the >> "front door" prefix on .indexeddb. >> >> I'm with Ben here. I'd prefer to hide the message away under a vendor >> prefix (either now or once you drop the front door one) for now to >> gather feedback on how it'll be used. >> I'm not sure about this...as I was catching up on the thread I understood this more as a debugging helper feature. In the end if we didn't have this you could just have a database-wide error handler and stash errors as they come in a global array or something, and that's okay for diagnostics. If we want to make it easier to just look at the transaction and see what happened, we may as well let UAs include a descriptive string so you can really find out on the spot. I don't have a strong opinion about excluding (or vendor-prefixing) the property, but it seems it would come in handy. -pablo
Received on Thursday, 10 February 2011 07:30:59 UTC