A bug in GDataServiceBase server error processing?

[Arseniy Kuznetsov]

Hello,

looking at the userInfoForErrorResponseData method, seems to rely on "([userInfo count] == 0)" for decision on whether to store plaintext server error response into the userInfo dictionary. Will not work reliably though, even when the structured XML error info is not available -- as earlier in the method there's already an attempt to put the
previousUserInfo entry into that dictionary. 

Greg, can you pls check?

thanks,

Arseniy

[Greg Robbins]

Are you saying it will not work reliably because there is always a non-empty previousUserInfo dictionary?

[Arseniy Kuznetsov]

Hi Greg,

yes, that's right.

Arseniy

On Mon, Apr 22, 2013 at 11:48 PM, Greg Robbins <grob...@google.com> wrote:

Are you saying it will not work reliably because there is always a non-empty previousUserInfo dictionary?

--
You received this message because you are subscribed to the Google Groups "Google Data APIs Objective-C Client Library Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gdata-objectivec-...@googlegroups.com.
To post to this group, send email to gdata-objec...@googlegroups.com.
Visit this group at http://groups.google.com/group/gdata-objectivec-client?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Greg Robbins]

The plaintext version of the server data is only provided for developer convenience. Usually it should be present, or else the reason from the previous error should be present. But if it's not, your app can always get the response body data and attempt to make a string from it, too:

NSData *data = [[ticket objectFetcher] downloadedData];

NSString *str = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];

As the Google Data APIs Objective-C Client library is not under active development, this behavior in the library is not likely to change.

[Arseniy Kuznetsov]

Hi Greg,

yes the structured server data is not there in my case and the plaintext is getting lost bcs of the problem I mentioned. 

The workaround would work of course, though given the library is not under active development would probably also make sense for me to fix the bug in my local copy.

thanks,

Arseniy