Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. I think at this point I've sort of lost track of what the proposal is. Is it simply making abort events look like error events, but obviously with .type set to abort. And give them codes which live side-by-side with the error codes? If so, that would be ok with me. I think that's what Ben was suggesting. I was suggesting that it seemed kind of odd though, and I'd prefer the following: Add the following to IDBTransaction: readonly attribute EXPLICIT_ABORT = 1 readonly attribute INTERNAL_ERROR_ABORT = 2 readonly attribute QUOTA_ERROR_ABORT=3 ... etc readonly attribute abortMessage; readonly attribute abortCode; And just set the message/code right before firing an abort event. Yeah, I think Jeremy is right. If we are going to expose the abort reason then this is way to do it. However, the above is somewhat ugly. Do we really need this feature? The only thing it seems like you can really make use of is the quota abort reason. When that happens you can show to the user a message like Unable to synchronize emails since you didn't give me enough quota. Knucklehead!. Maybe a cleaner solution could be designed that only let you tell that condition from other aborts. Did you have a use case in mind for the other types of aborts? The one thing I could think of is being able to log errors and report them back to the server. For example if you detect that you're getting a lot of user leaving page-aborts, you might
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. I think at this point I've sort of lost track of what the proposal is. Is it simply making abort events look like error events, but obviously with .type set to abort. And give them codes which live side-by-side with the error codes? If so, that would be ok with me. I think that's what Ben was suggesting. I was suggesting that it seemed kind of odd though, and I'd prefer the following: Add the following to IDBTransaction: readonly attribute EXPLICIT_ABORT = 1 readonly attribute INTERNAL_ERROR_ABORT = 2 readonly attribute QUOTA_ERROR_ABORT=3 ... etc readonly attribute abortMessage; readonly attribute abortCode; And just set the message/code right before firing an abort event. Yeah, I think Jeremy is right. If we are going to expose the abort reason then this is way to do it. However, the above is somewhat ugly. Do we really need this feature? The only thing it seems like you can really make use of is the quota abort reason. When that happens you can show to the user a message like Unable to synchronize emails since you didn't give me enough quota. Knucklehead!. Maybe a cleaner solution could be designed that only let you tell that condition from other aborts. Did you have a use case in mind for
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. I think at this point I've sort of lost track of what the proposal is. Is it simply making abort events look like error events, but obviously with .type set to abort. And give them codes which live side-by-side with the error codes? If so, that would be ok with me. I think that's what Ben was suggesting. I was suggesting that it seemed kind of odd though, and I'd prefer the following: Add the following to IDBTransaction: readonly attribute EXPLICIT_ABORT = 1 readonly attribute INTERNAL_ERROR_ABORT = 2 readonly attribute QUOTA_ERROR_ABORT=3 ... etc readonly attribute abortMessage; readonly attribute abortCode; And just set the message/code right before firing an abort event. Yeah, I think Jeremy is right. If we are going to expose the abort reason then this is way to do it. However, the above is somewhat ugly. Do we really need this feature? The only thing it seems like you can really make use of is the quota abort reason. When that happens you can show to the user a message like Unable to synchronize emails since you didn't give me enough quota. Knucklehead!. Maybe a cleaner solution
Re: [IndexedDB] Reason for aborting transactions
Hm, Jeremy is right, If you want to look just at the transaction and see why it aborted you can't rely on errorCode. Ick. The only thing I'd change then is the abortMessage property. It's easier to tell why your transaction aborted with the error code, and I'd hate people doing string comparisons instead of checking the error code. And what about localization? -Ben
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 5:17 PM, ben turner bent.mozi...@gmail.com wrote: Hm, Jeremy is right, If you want to look just at the transaction and see why it aborted you can't rely on errorCode. Ick. The only thing I'd change then is the abortMessage property. It's easier to tell why your transaction aborted with the error code, and I'd hate people doing string comparisons instead of checking the error code. And what about localization? Normal exceptions have error messages that are not consistient across implementations and are not localized. What's the difference? For stuff like internal errors, they seem especially important. J
Re: [IndexedDB] Reason for aborting transactions
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? -Ben
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 5:37 PM, ben turner bent.mozi...@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. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 8:37 PM, ben turner bent.mozi...@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). FWIW, I think that any scripting error message useful to display on the console is useful to make accessible from scripts, provided they don't contain sensitive information, like database paths. I often attach a global error handler to window.onerror and send script errors to the server automatically, which is indispensable for quickly discovering lurking bugs on user systems. This is particularly important if there's more specific information in the message than the exception itself, which seems likely with error codes like internal error. (It's somewhat frustrating when they come back localized, but bearable.) -- Glenn Maynard
Re: [IndexedDB] Reason for aborting transactions
(It's somewhat frustrating when they come back localized, but bearable.) Sounds like what you really want is more specific error codes, not really messages, right? -Ben
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 9:04 PM, ben turner bent.mozi...@gmail.com wrote: (It's somewhat frustrating when they come back localized, but bearable.) Sounds like what you really want is more specific error codes, not really messages, right? Not always: - Some errors are implementation-specific. For example, if internal error is caused by SQLite under the hood returning an unexpected error that the browser can't recover from, the browser could include the SQLite error message. That's not something that should be specced specifically, but it may be very helpful on the developer's side to knowing what went wrong on a user's system to be able to follow up the problem. Similarly, if a File-API write fails due to EDQUOT because of the user's hard disk quota (not to be confused with the browser's quota), receiving strerror(EDQUOT) as part of the message would be very useful, but shouldn't be laid out as a specific error code in the spec. - Some errors contain other information that may not be implementation-specific, but may not be worth codifying into the spec. For example, it's not worth trying to encode an error message for every possible Regex parsing failure. Browsers may also give additional information that's not useful to spec; for example, 17 in open parentheses at pos 17 not closed. Javascript parsing failures might include the context of a compilation error. Error codes are useful when there are meaningful ways for a script to respond to a particular type of failure, but there's not much you can do in response to EDQUOT beyond displaying and/or reporting the error--the same is probably true for most implementation-specific database internal errors and so on. -- Glenn Maynard
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 6:39 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Feb 9, 2011 at 9:04 PM, ben turner bent.mozi...@gmail.com wrote: (It's somewhat frustrating when they come back localized, but bearable.) Sounds like what you really want is more specific error codes, not really messages, right? Not always: - Some errors are implementation-specific. For example, if internal error is caused by SQLite under the hood returning an unexpected error that the browser can't recover from, the browser could include the SQLite error message. That's not something that should be specced specifically, but it may be very helpful on the developer's side to knowing what went wrong on a user's system to be able to follow up the problem. Similarly, if a File-API write fails due to EDQUOT because of the user's hard disk quota (not to be confused with the browser's quota), receiving strerror(EDQUOT) as part of the message would be very useful, but shouldn't be laid out as a specific error code in the spec. Note that in both these cases the browser probably doesn't want to forward the message it gets from the OS or from SQLite directly to the webpage. Such a message can contain sensitive information such as usernames and filenames. - Some errors contain other information that may not be implementation-specific, but may not be worth codifying into the spec. For example, it's not worth trying to encode an error message for every possible Regex parsing failure. Browsers may also give additional information that's not useful to spec; for example, 17 in open parentheses at pos 17 not closed. Javascript parsing failures might include the context of a compilation error. This is more interesting, but I'm not sure that it applies to abort codes? The one case I can think of is unhandled errors which result in an abort. However in that case we should have already fired window.onerror with the information you're talking about. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 5:37 PM, ben turner bent.mozi...@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. It's common for people to do something like this: indexeddb = indexeddb || moz_indexedDB || mozIndexedDB || webkitIndexedDB; and then pretty much ignore which vendor's implementation they're using from then on whenever possible, so I think it's worth doing a prefix on every level of vendor specific stuff. So we'll definitely use a prefix for the abort message. And I'd encourage you to do the same with getAll if you can before FF4 ships. J
Re: [IndexedDB] Reason for aborting transactions
On Wed, Feb 9, 2011 at 9:46 PM, Jonas Sicking jo...@sicking.cc wrote: - Some errors are implementation-specific. For example, if internal error is caused by SQLite under the hood returning an unexpected error that the browser can't recover from, the browser could include the SQLite error message. That's not something that should be specced specifically, but it may be very helpful on the developer's side to knowing what went wrong on a user's system to be able to follow up the problem. Similarly, if a File-API write fails due to EDQUOT because of the user's hard disk quota (not to be confused with the browser's quota), receiving strerror(EDQUOT) as part of the message would be very useful, but shouldn't be laid out as a specific error code in the spec. Note that in both these cases the browser probably doesn't want to forward the message it gets from the OS or from SQLite directly to the webpage. Such a message can contain sensitive information such as usernames and filenames. Right; it's the implementation's job to pay attention to where its messages are coming from. For example, you shouldn't blindly forward an error message string from a database backend (which may include paths). However, returning a stringification of SQLITE_* constants or strerror(errno), seems perfectly safe and very useful. - Some errors contain other information that may not be implementation-specific, but may not be worth codifying into the spec. For example, it's not worth trying to encode an error message for every possible Regex parsing failure. Browsers may also give additional information that's not useful to spec; for example, 17 in open parentheses at pos 17 not closed. Javascript parsing failures might include the context of a compilation error. This is more interesting, but I'm not sure that it applies to abort codes? The one case I can think of is unhandled errors which result in an abort. However in that case we should have already fired window.onerror with the information you're talking about. I was looking over the spec on success and error events some more while considering this, and I'm deeply confused: 3.2.2 describes the success and error events being fired at the Window (at each Window object) rather then at the request, which seems bizarre. I feel like this is an embarrassing spec-novice question, but could someone clue me in on what's happening here? -- Glenn Maynard
RE: [IndexedDB] Reason for aborting transactions
(back!) From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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 jo...@sicking.cc wrote: On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 5:37 PM, ben turner bent.mozi...@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
Re: [IndexedDB] Reason for aborting transactions
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. / Jonas
Re: [IndexedDB] Reason for aborting transactions
Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. -Ben On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. J
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. I think at this point I've sort of lost track of what the proposal is. Is it simply making abort events look like error events, but obviously with .type set to abort. And give them codes which live side-by-side with the error codes? If so, that would be ok with me. / Jonas
Re: [IndexedDB] Reason for aborting transactions
I think that's what Ben was suggesting. Yes. We already have ABORT_ERR, no reason we can't subdivide that since it's being overloaded. In fact I think it makes perfect sense. Add the following to IDBTransaction: I'm really not a fan of making IDBTransaction more complicated. We already have a generic tell me when something goes wrong, and why mechanism via errorCode and onError/onAbort. Why add another one? If the name is confusing we could rename it to exceptionCode perhaps? readonly attribute abortMessage; We dropped errorMessage already, let's not add abortMessage. And just set the message/code right before firing an abort event. And what happens when someone calls .abortCode before the transaction has finished? Or if the transaction succeeded? Or if the transaction failed for some other reason? I think we'd probably want the same behavior as calling .errorCode, so again I think we should just roll the specific abort reasons into error codes and stick with our existing mechanism. -Ben
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 11:37 AM, ben turner bent.mozi...@gmail.com wrote: I think that's what Ben was suggesting. Yes. We already have ABORT_ERR, no reason we can't subdivide that since it's being overloaded. In fact I think it makes perfect sense. That part of the spec seems completely broken (there are no steps to abort a transaction in the spec and it's not clear how ABORT_ERR would be plugged in). Either way, ABORT_ERR should probably be removed. Add the following to IDBTransaction: I'm really not a fan of making IDBTransaction more complicated. We already have a generic tell me when something goes wrong, and why mechanism via errorCode errorCode is something on the IDBRequest object these days, right? Clearly we can't use that when we're in an abort handler to figure out why we were aborted. I'm pretty sure we need to add a code (no matter what we name it and where the code enums live) to IDBtransaction. and onError/onAbort. Why add another one? If the name is confusing we could rename it to exceptionCode perhaps? readonly attribute abortMessage; We dropped errorMessage already, let's not add abortMessage. We did? When and why? I think the text based messages can be very useful for debugging. And they're there for exceptions. And just set the message/code right before firing an abort event. And what happens when someone calls .abortCode before the transaction has finished? Or if the transaction succeeded? What happens when you try to access the error code on IDBRequest today? (Serious question, I don't remember.) Or if the transaction failed for some other reason? If it fails for any reason, it'll result in an abort. I think we'd probably want the same behavior as calling .errorCode, so again I think we should just roll the specific abort reasons into error codes and stick with our existing mechanism. The existing mechanism doesn't fix the use case of being in an abort event handler and wanting to know why you aborted. J
Re: [IndexedDB] Reason for aborting transactions
On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? And maybe revisit in the future? J
Re: [IndexedDB] Reason for aborting transactions
On Fri, Jan 28, 2011 at 2:35 PM, Jeremy Orlow jor...@chromium.org wrote: Given that transactions can be aborted because of explicit action, internal errors, quota errors, and possibly other things in the future, I'm wondering if we should add some way for people to find out why the transaction was aborted. Thoughts? Hmm.. not a bad idea. We also abort transactions if the user leaves the current page in the middle of a transaction. Don't remember if the spec requires this or not, but it might make sense to do so. / Jonas
