sanvlr12 / google-api-dotnet-client

Automatically exported from code.google.com/p/google-api-dotnet-client
0 stars 0 forks source link

Error during ExecuteRequest doesn't bubble up? #142

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Calling ExecuteRequest() can sometimes throw a GoogleApiException (in my case, 
because the user hasn't authorized Latitude) -- but this is only being caught 
if I'm attached to the debugger, a standard try/catch doesn't catch the 
Exception, and in fact the execution of the code just sits/stalls out on 
ExecuteRequest.

Original issue reported on code.google.com by nicho...@lewistech.com on 15 Sep 2011 at 9:33

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by asky...@google.com on 3 Oct 2011 at 11:53

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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