(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 wrote:
>> On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote:
>> > On Wed, Feb 9, 2011 at 5:3
On Wed, Feb 9, 2011 at 9:46 PM, Jonas Sicking 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
> > mess
On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking wrote:
> On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote:
> > On Wed, Feb 9, 2011 at 5:37 PM, ben turner
> wrote:
> >>
> >> > Normal exceptions have error messages that are not consistient across
> >> > implementations and are not localized. Wha
On Wed, Feb 9, 2011 at 6:39 PM, Glenn Maynard wrote:
> On Wed, Feb 9, 2011 at 9:04 PM, ben turner 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 alw
On Wed, Feb 9, 2011 at 9:04 PM, ben turner 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,
> (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
On Wed, Feb 9, 2011 at 8:37 PM, ben turner 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.
On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote:
> On Wed, Feb 9, 2011 at 5:37 PM, ben turner 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 excepti
On Wed, Feb 9, 2011 at 5:37 PM, ben turner 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.
> 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
On Wed, Feb 9, 2011 at 5:17 PM, ben turner 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
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
On Wed, Feb 9, 2011 at 4:03 PM, Jeremy Orlow wrote:
> On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking wrote:
>>
>> On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote:
>> > On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote:
>> >>
>> >> On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow
>> >> wrote:
On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking wrote:
> On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote:
> > On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote:
> >>
> >> On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow
> wrote:
> >> > On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking
> wrote:
>
On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote:
> On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote:
>>
>> On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow wrote:
>> > On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote:
>> >>
>> >> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow
>> >> wrote:
On Tue, Feb 8, 2011 at 11:37 AM, ben turner 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 n
> 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
On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote:
> On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow wrote:
> > On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote:
> >>
> >> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow
> wrote:
> >> > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking
> wrote:
>
On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow wrote:
> On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote:
>>
>> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote:
>> > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote:
>> >>
>> >> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow
>> >> wrote:
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote:
> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote:
> > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote:
> >>
> >> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow
> wrote:
> >> > We do that as well.
> >> > What's the best way to do it AP
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 wrote:
> On Mon, Feb 7, 2011 at 8:05 PM, Je
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote:
> On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote:
>>
>> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow 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 er
On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote:
> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow 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
On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow 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 differe
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?
J
On Fri, Jan 28, 2011 at 4:31 PM, Jonas Sicking wrote:
> On Fri, Jan 28, 2011 at 2:35 PM, Jeremy Orlow wrote:
> > Given that transactions can be aborted beca
On Fri, Jan 28, 2011 at 2:35 PM, Jeremy Orlow 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.
>
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?
J
27 matches
Mail list logo
