On Dec 8, 4:04 pm, "[email protected]" <[email protected]> wrote: > Your tools should let you deal with this issue. If .NET won't then it > is broken, not the API... > > Have you tried handling the exception? > Yeah, I am handling the error, but I have to make the assumption that it's a 620 any time it throws the 403 error, since I can't see into the response. I agree that the .NET HttpRequest object is broken in this case. A response is a response, regardless of the status code, so I should be able to receive it and read the code myself to determine whether it's an exception or not. I dug through the docs but wasn't able to find any way to make that object not throw an exception on a 403 response. I was hoping someone else might've found a creative way to handle this, other than simply trapping the error and assuming it's a 620.
In my situation, I have a google appliance that does regular crawls of the site, and when it does, it hits ~10k pages that do a geocoding request in rapid succession, so every couple of days the site exceeds its usage limit. Unfortunately, the geocoding requests have to take place at the server and not the client, so they all go towards the server address' usage count. No good way around this other than to trap the error, log it, and ignore it when it happens, and just know that latlongs won't be updated during that time. ryanm -- You received this message because you are subscribed to the Google Groups "Google Maps 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-maps-api?hl=en.
