I agree with the exceptions, but so far i could not really come up with a good
layer that is not just duplicating the information in the underlying exception.

So all we have is the responseText property so far to make it a bit easier to
get at the errorHTML from the server.

Do you have some suggestions on what type of exception subclasses you like to see,
and what they should expose?

Frank Mantek

On 10/5/06, Dinana <[EMAIL PROTECTED]> wrote:

Thanks Frank for the tip,

I changed it through the service's factory after creating the service.
This way is definately cleaner than editing the source code for the
authrequestfactory. However I cast the factory into
GDataAuthRequestFactory instead of a GAuthRequestFactory.

I noticed this happens the most while debugging, maybe the keep-alive
timeouts while looking at some values/code, also when there are
subsequent calls (in a loop for instance) with other time-consuming
statements seperating them. Also it definately happens when a torrent
is eating up most of my bandwidth :0), but no proxies.

I wanted to point out that the way the cs library generates exceptions
is very uninformative and not really useful; I get the same exception
when I query a wrong or malformed URL, and also when there are
connectivity problems and that I have to look into the inner exception
in my code. I hope we have several exception classes in the next
releases.

Thank you for the help, I would love to help with the APIs if possible,
Mootaz Dinana

On Oct 5, 9:47 am, "Frank Mantek" <[EMAIL PROTECTED]> wrote:
> Actually,
>
> when you look at the GDataAuthRequestFactory, you can set the number of
> retries there.
>
> So, what you would do is:
>
>         GAuthRequestFactory factory = (GAuthRequestFactory) service.factory;
>         factory.NumberOfRetries = 3;
>
> And yes, this is supported either way. I put the retry loop in when i was
> debugging the intermittend closure happening under .NET 2.0, and when i
> fixed the bug i decided that there might be scenarios where you have an
> unreliable connection for whatever reasons, and hence this is not a bad
> feature to have.
>
> You should still try to figure out why this happens. Proxy server?
>
> Frank Mantek
>
> On 10/5/06, Dinana <[EMAIL PROTECTED]> wrote:
>
>
>
> > I am building a project using the cs library, however if several
> > subsequent calls are made to Google Calendar service I get a
> > GDataRequestException with an inner exception saying that the
> > underlying connection has been closed and so authentication cannot be
> > performed successfully. This behaviour is random and not regular.
>
> > I found out that this happens in the following clause in
> > gauthrequest.cs:
>
> >                     if (iRetrying > this.factory.NumberOfRetries)
> >                     {
> >                         Tracing.TraceMsg("Got no response object");
> >                         throw re;
> >                     }
>
> > I decided to increase the NumberOfRetries parameter to 2 in the
> > constructor since it originally set the NumberOfRetries to 0:
>
> >         public GDataGAuthRequestFactory(string service, string
> > applicationName) : base(applicationName)
> >         {
> >             this.Service = service;
> >             this.ApplicationName = applicationName;
> >             if (applicationName != null) {
> >                 this.UserAgent = applicationName + " " + GDataGAuthAgent;
> >             } else {
> >                 this.UserAgent = GDataGAuthAgent;
> >             }
> >             this.numberOfRetries = 2;
> >         }
>
> > N.B. This is the only place where numberOfRetries is modified in this
> > class.
>
> > Is this supported tested in the API or does it have any known side
> > effects?
>
> > Thanks



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi
-~----------~----~----~----~------~----~------~--~---

Reply via email to