Closed GoogleCodeExporter closed 9 years ago
This is the error I see if I'm attached via debugger-- otherwise if I'm not
attached, execution just hangs on the ExecuteRequest() call, as I stated.
Server error - Google.Apis.Requests.RequestError
The user is not opted in to Google Latitude. [403]
Errors [
Message[The user is not opted in to Google Latitude.] Location[ - ] Reason[insufficientPermissions] Domain[global]
]
It seems like ExecuteRequest isn't returning errors non-synchronously?
Original comment by nicho...@lewistech.com
on 15 Sep 2011 at 9:35
Are you using .FetchAsync? If yes, you should be able to catch errors by
specifying a callback function:
request.FetchAsync((lazyResult) =>
{
try
{
lazyResult.GetResult(); // or var obj = ... in case this returns sth.
}
catch (GoogleApiException ex)
{
// do something here
}
);
The normal .Fetch function on the other hand should always throw a catchable
exception. Can you confirm whether this solution works/this is a bug?
Original comment by mlinder...@gmail.com
on 15 Sep 2011 at 10:33
I'm just calling .ExecuteRequest() (and not ExecuteRequestAsync()) -- does that
make sense? I can post code if needed.
Original comment by nicho...@lewistech.com
on 16 Sep 2011 at 3:37
Hmm, even the normal Request.ExecuteRequest() method should throw the exception
as soon as .GetResult() is called internally. If it doesn't, then this is
definitely a bug.
But is there any reason you are using the dynamic Request class instead of the
strongly typed library? Every supported API should also support the strongly
typed library surface, which is easier to use & the recommended way.
Original comment by mlinder...@gmail.com
on 16 Sep 2011 at 5:59
I thought I was-- maybe I'm not? Here's my code; please advise if I'm doing
something wrong. To be honest there isn't that much documentation (that I could
find) for what I'm doing:
var service = new LatitudeService(_auth);
var req = service.CreateRequest("location", "list");
var paramz = new List<KeyValuePair<string, string>>
{
new KeyValuePair<string, string>("granularity", "best"),
new KeyValuePair<string, string>("max-results", "1000")
};
req.WithParameters(paramz);
IResponse streamResponse;
try
{
streamResponse = req.ExecuteRequest();
}
catch (GoogleApiException googleApiException)
{
Trace.TraceError("Google API reported an error: " + googleApiException.ToString());
return null;
//throw;
}
var rdr = new StreamReader(streamResponse.Stream);
string str = rdr.ReadToEnd();
var responseObj = JObject.Parse(str);
Original comment by nicho...@lewistech.com
on 17 Sep 2011 at 12:31
Wow, I feel dumb. I see exactly what you're talking about now
(service.Location.List())
However, I still think there's an issue with the generic ExecuteRequest not
throwing the exception proper.
Original comment by nicho...@lewistech.com
on 19 Sep 2011 at 6:27
I am guessing that you are back working properly now, the ExecuteRequest is not
intended to be used directly, but we will look into it for the full release.
Original comment by asky...@google.com
on 19 Sep 2011 at 6:46
Actually it looks like the regular .Fetch() is also not throwing the exception
proper. You can try this yourself by attempting to get your Latitude list
without Latitude being enabled on your account-- expected behavior is for a
GoogleApiException to be thrown, but it's not, just sits there frozen. Thanks
for your help with this, by the way.
Original comment by nicho...@lewistech.com
on 19 Sep 2011 at 7:01
Original comment by asky...@google.com
on 3 Oct 2011 at 11:53
I'm having the same problem with the Translation API where I call
TranslationsListResponse response = service.Translations.List(textsToTranslate,
"en").Fetch();
within a try/catch without being able to catch the GoogleApiException.
Is there a way to catch that error?
Regards
Fredrik
Original comment by fredrik....@netsurvey.se
on 8 Nov 2011 at 5:46
This issue has been fixed in newer versions of the library. You can build the
library from source or wait for 1.1 beta release coming out very soon.
Original comment by asky...@google.com
on 8 Nov 2011 at 5:56
Original issue reported on code.google.com by
nicho...@lewistech.com
on 15 Sep 2011 at 9:33