Proposal 0.8 - Add getErrorMessage to DataResponse

[Louis Ryan]

Hi,

There is no simple mechanism in the spec to specify an error occurred at the Datarequest/Dataresponse level rather than the more granular ResponseItem level. For example if there was a 500 err making the XMLHttprequest we have no good way to convey that information to the developer.

Proposal:
Dataresponse.hadError returns true if there was an HTTP (or other batch level) error or an error processing an element of the batch
DataResponse.getErrorMessage returns a message describing the batch-level error if it exists otherwise undefined

Im not sure theres alot of value in adding an enumeration of possible failure modes like ResponseItem.Error but I could be convinced

-Louis

[Cassie]

Did you want a dataResponse.getError as well? or just errorMessage?

[Louis Ryan]

Seeing as theres no valid enum of error types I think just getErrorMessage is sufficient.

[Arne Roomann-Kurrik (Google)]

+1

On Apr 21, 10:59 am, "Louis Ryan" <lr...@google.com> wrote:
> Seeing as theres no valid enum of error types I think just getErrorMessage
> is sufficient.
>

[Lane LiaBraaten]

+1 for getErrorMessage

[Robert Evans]

+1

[Cassie]

Okay, so Louis, Lane, Arne and Bob are for this.

Louis - just a quick mention, couldn't a getError() method just reuse the error codes currently defined on ResponseItem? Those are all http error codes... so it seems to fit. (especially internal error or forbidden)

If those don't fit, just curious, what types of error messages will you be returning?
Thanks.

- Cassie

[Louis Ryan]

Do we want to add cases for pretty common HTTP responses to ResponseItem.Error then?

temporarily unavailable,  host unreachable, ....

or just return that status information from the XHR object which would include the HTTP response code in the error message and leave it at that. I would prefer the latter.

[Arne Roomann-Kurrik]

I like the latter approach as well - might as well keep the data in a format that developers are already familiar with.

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Robert Evans]

Agree

[Zhen Wang]

+1

On Fri, Apr 25, 2008 at 11:18 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

[mnew...@myspace.com]

+1, xhr status being returned in the error message.

On Apr 25, 11:22 am, Robert Evans <bobev...@google.com> wrote:
> Agree
>
> On Fri, Apr 25, 2008 at 11:18 AM, Arne Roomann-Kurrik <kur...@google.com>
> wrote:
>
> > I like the latter approach as well - might as well keep the data in a
> > format that developers are already familiar with.
>
> > ~Arne
>
> > On Fri, Apr 25, 2008 at 10:32 AM, Louis Ryan <lr...@google.com> wrote:
>
> >> Do we want to add cases for pretty common HTTP responses to
> >> ResponseItem.Error then?
>
> >> temporarily unavailable, host unreachable, ....
>
> >> or just return that status information from the XHR object which would
> >> include the HTTP response code in the error message and leave it at that. I
> >> would prefer the latter.
>

> >> On Fri, Apr 25, 2008 at 4:14 AM, Cassie <d...@google.com> wrote:
>
> >>> Okay, so Louis, Lane, Arne and Bob are for this.
>
> >>> Louis - just a quick mention, couldn't a getError() method just reuse the
> >>> error codes currently defined on ResponseItem? Those are all http error
> >>> codes... so it seems to fit. (especially internal error or forbidden)
>
> >>> If those don't fit, just curious, what types of error messages will you
> >>> be returning?
> >>> Thanks.
>
> >>> - Cassie
>

> >>> On Fri, Apr 25, 2008 at 8:39 AM, Robert Evans <bobev...@google.com>
> >>> wrote:
>
> >>>> +1
>
> >>>> On Thu, Apr 24, 2008 at 4:41 PM, Lane LiaBraaten <lliab...@google.com>

[Paul]

+1

I would prefer to see the error pattern on DataResponse match that of
ResponseItem. Perhaps some error enum values that are currently
defined in the responseItem error are more appropriate at this level.
Maybe it would be cleaner for the developer to always check http level
related errors at the DataResponse level and be assured that
ResponseItem errors are only policy/permission/context errors.

~Paul

[Cassie]

Okay, this has gotten enough votes so getErrorMessage being added as a method to the dataResponse object is approved.

Paul - these are good considerations to keep in mind. We may want to further improve our error reporting in many different ways. Perhaps we should come up with a complete proposal for 0.9 and take this current change as just a first step.

Thanks!

- Cassie