W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2008

RE: skeleton Geolocation API - Error codes

From: Shyam Habarakada <shyamh@microsoft.com>
Date: Mon, 28 Jul 2008 14:22:06 -0700
To: Andrei Popescu <andreip@google.com>
CC: Alec Berntson <alecb@windows.microsoft.com>, Chris Butler <cbutler@dash.net>, Doug Turner <doug.turner@gmail.com>, Chris Prince <cprince@google.com>, Aaron Boodman <aa@google.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>
Message-ID: <F2726D43C21D084F81F9C887BE881BD155150681D1@NA-EXMSG-C105.redmond.corp.microsoft.com>

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
Received on Monday, 28 July 2008 21:22:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT