RE: skeleton Geolocation API - Error codes

Inline

-----Original Message-----
> From: Andrei Popescu [mailto:andreip@google.com]
>
> Hi Shyam,
>
> <snip />
>
> Would these suffice, or do you see reasons why we would want to have
> more detailed errors? Specifically, I'm wondering about "TimeOut" and
> the bubbling of HTTP response codes. To me, these all mean roughly the
> same thing: there was something wrong with the network location
> provider.

I think TimeOut is important - Consumers of the API can check this and present end-users with a "Try again" option or auto-retry, etc. Note that this scenario is different from say, NotFound or a generic error.

Bubbling up service error codes would be a _huge_ help for debugging (imagine life as a programmer if these were hidden). I don't anticipate consumers of the API using these to determine end user experience though.

Pseudo code for error handling may look like:

void errorCallback(positionError)
{
    debug.assert(positionError != null);

    switch(positionError.id)
    {
        case 1:
        case 3:
            // AccessDenied or NotFound
            // Continue without location information ...
            break;
        case 2:
            // TimeOut
            // Prompt user to re-try or abort...
            break;

#if(DEBUG)
        case 401:
        case 402:
        case 403:
        case 404:
        case 500:
        case 503:
            // Service errors
            // Do debug only stuff...
            break;
#endif

        default:
            // UnhandledException
            // Do something sensible
    }
}


Furthermore, given that errors are handled in callbacks, I take back my suggestion to throw on unhandled errors.

Thanks
shyam