Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On Wed, Dec 15, 2010 at 3:42 AM, Jonas Sicking jo...@sicking.cc wrote: Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) Is this things like disk IO errors and the like? Yeah and other impossible conditions. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? Ideal is if you can leave out the function entirely if you don't implement it yet. An example is autoIncrement. There isn't really any way to leave it out because we otherwise support creating object stores and silently ignoring it means that we don't behave the way a user would expect. If there were mature IndexedDB implementations, we would have blocked releasing anything until we were feature complete, but until then I think it's better for everyone that we release early and often so we can get feedback. When this isn't possible, I would say that you should throw something different from what could be legitimately thrown from the function. I know gecko has a special exception we throw from various places when functionality isn't implemented. I don't think we should put anything in the spec about this as the spec should specify that everything should be implemented :) I agree. Wasn't asking because I wanted to add anything to the spec. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item It's currently specced to throw NOT_ALLOWED_ERR. I think this is consistent with other uses of that exception. I see now. In the text at the top it does actually say this clearly, but in the table below it only talks about hitting the end of results. (or that item has been deleted)? I brought up this a while back in bug 11257. Note that you can't throw since you can't synchronously know if an item has been deleted. IMHO the simplest thing is to just treat IDBCursor.update the same as IDBObjectStore.put and IDBCursor.delete as IDBObjectStore.delete. I can't think of a use case for deleting and then wanting to ensure that IDBCursor.update doesn't create a new entry, so we might as well keep things simple and reuse the implementation and spec logic. In short, I think the spec is fine in this area. TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Yes, along with RECOVERABLE_ERR, NON_TRANSIENT_ERR and DEADLOCK_ERR. We should also remove the .message property. DOMException doesn't have that. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I intend to tackle this early next week unless there are major areas of contention. Sounds great. The only possible thing that we might want to do differently is that we might want to get rid of IDBDatabaseException entirely and just add values to DOMException. I don't have an opinion on this but I'm currently checking with JS developers what is easiest for them. (In general I'm not a fan of how exceptions in the DOM are so different from JS-exceptions). Other APIs have their own exception classes. What's the benefit of putting our exceptions in DOMException? The downside is that other specs need to coordinate with our exception codes. Unless there's a pretty compelling reason to do this, I don't think we should. J
RE: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 5:03 AM I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. It sounds like a good idea to keep QUOTA_ERR separated from other general errors that come up when writing stuff to disk. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) That sounds reasonable to me. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? I don't think it's a big deal, but are we going to have a bunch of unimplemented stuff across browsers? If this becomes common, I wonder if we should have a separate error so calling code can choose to compensate or something. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? NOT_ALLOWED_ERR? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Sure. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I'm fine with that. -pc
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On Wed, Dec 15, 2010 at 12:08 AM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 5:03 AM I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. It sounds like a good idea to keep QUOTA_ERR separated from other general errors that come up when writing stuff to disk. I'll re-add it then. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) That sounds reasonable to me. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? I don't think it's a big deal, but are we going to have a bunch of unimplemented stuff across browsers? If this becomes common, I wonder if we should have a separate error so calling code can choose to compensate or something. Hopefully it won't be a big deal. I think most browsers are a bit more fast and loose with shipping half working things before anyone else has shipped something rock solid (that people are using in production). I expect that our couple instances of this will go away pretty soon. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? NOT_ALLOWED_ERR? Shawn said NOT_FOUND_ERR. NOT_ALLOWED_ERR seems slightly better to me. Shawn, what do you think? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Sure. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I'm fine with that. -pc
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On 12/14/2010 4:16 PM, Jeremy Orlow wrote: Shawn said NOT_FOUND_ERR. NOT_ALLOWED_ERR seems slightly better to me. Shawn, what do you think? I don't have a strong opinion either way. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
I was confused re not overlapping with other exception codes. As long as we don't have overlap within this particular exception type, we're OK. I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I intend to tackle this early next week unless there are major areas of contention. J On Mon, Nov 22, 2010 at 12:43 PM, bugzi...@jessica.w3.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11375 Summary: [IndexedDB] Error codes need to be assigned new numbers Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The error codes specced in IDBDatabaseException's interface need to be redone. They currently overlap with existing exception error codes and use 0 which we've avoided using in the past [0]. In addition, the codes are non-contiguous which also seems to be non-standard. We should re-map the exception numbers into something contiguous that doesn't overlap with other exception codes. [0] I'm not sure if 0 is actually specced to be reserved, but in practice it seems to be. And WebKit uses 0 internally to signal no exception. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On 12/10/2010 5:03 AM, Jeremy Orlow wrote: Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) Would a CONSTRAINT_ERR make more sense? What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? I think NOT_FOUND_ERR makes sense there. TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? I can't think of anything that we'd actually want to use it for. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I think it is fine to just renumber. If anyone is relying on the numbers being a certain thing now, I think it's probably best just to have a clean break instead of sometimes being right still. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On Fri, Dec 10, 2010 at 6:01 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 12/10/2010 5:03 AM, Jeremy Orlow wrote: Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) Would a CONSTRAINT_ERR make more sense? This error doesn't really apply to internal implementation issues in my mind. In addition, some of the places we can hit this also return CONSTRAINT_ERRs for other reasons. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? I think NOT_FOUND_ERR makes sense there. Sounds good to me. TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? I can't think of anything that we'd actually want to use it for. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I think it is fine to just renumber. If anyone is relying on the numbers being a certain thing now, I think it's probably best just to have a clean break instead of sometimes being right still. Cheers, Shawn
