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>


-----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);

        case 1:
        case 3:
            // AccessDenied or NotFound
            // Continue without location information ...
        case 2:
            // TimeOut
            // Prompt user to re-try or abort...

        case 401:
        case 402:
        case 403:
        case 404:
        case 500:
        case 503:
            // Service errors
            // Do debug only stuff...

            // UnhandledException
            // Do something sensible

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

Received on Monday, 28 July 2008 21:22:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC