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

Re: skeleton Geolocation API - Error codes

From: Andrei Popescu <andreip@google.com>
Date: Mon, 28 Jul 2008 21:42:56 +0100
Message-ID: <708552fb0807281342r394f9990p5cf7f83f11c62d11@mail.gmail.com>
To: "Shyam Habarakada" <shyamh@microsoft.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>

Hi Shyam,

I agree that this topic deserves its own thread. Chris was also right
to point out that now it's a good time to discuss the error types we
want to handle.

Since we have so far opted for simplicity, what if we had something
simple here, as well? We could start by looking at the errors that a
developer would be interested in:

- programming errors (wrong type of parameters): an implementation
would probably deal with these by immediately throwing an exception
so, for the purposes of this spec, we are not concerned with such

- access error: same as in your proposal

- something wrong with the environment:
  - The device simply cannot provide a location at all (similar to
NotAvailable in your proposal). As suggested, we could mandate that
the navigator.geolocation is null or undefined.
  - None of the available providers could be used for acquiring a fix.
For example, this can happen when the onboard GPS is disabled and the
network location provider is temporarily down or returning bad
  - The position was not found (similar to NotFound) : everything went
well, it's just that the network location provider could not tell
where the user is (e.g. because it's missing the data for a certain

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


On Mon, Jul 28, 2008 at 7:17 PM, Shyam Habarakada <shyamh@microsoft.com> wrote:
> // Modified subject to fork this discussion
> Here's an updated of errorIds and descriptions to also include service errors:
> /* Errors that can occur on the user-agent/client
>  */
> 001 AccessDenied        // User (or policy on user-agent) denied access to geolocation
> 002 TimeOut             // Async operation timed out
> 003 NotFound            // Position could not be determined
> 004 NotAvailable        // Position features are not available on this user-agent
>                        // This could be the same as window.geolocation == undefined
> /* Errors that can occur when trying to use a cloud resolver service.
>  * We should be able to directly buble up the HTTP response codes for
>  * these 'service' related errors as indicated below.
>  */
> 400 Service_BadRequest
> 401 Service_Unauthorized
> 402 Service_PaymentRequired
> 403 Service_Forbidden
> 404 Service_NotFound
> 500 Service_Failed
> 503 Service_TooBusy
> etc.
> /* A catch all error. We should decide if it is better to throw in this scenario
>  */
> UnhandledException      // A catch all error for anything else
> Thanks
> shyam habarakada
> Microsoft Corporation
> -----Original Message-----
> From: Alec Berntson
> Sent: Monday, July 28, 2008 11:10 AM
> To: Chris Butler; Andrei Popescu; Shyam Habarakada
> Cc: Doug Turner; Chris Prince; Aaron Boodman; public-geolocation@w3c.org
> Subject: RE: skeleton Geolocation API
> Here's what I was thinking:
> NotSupported (not providers)
> Error           (generic)
> Timeout         (call to provider took too long)
> AccessDenied (user hasn't given permission to this site/app)
> Running         (Location acquisition is working)
> -----Original Message-----
> From: Chris Butler [mailto:cbutler@dash.net]
> Sent: Monday, July 28, 2008 10:10 AM
> To: Andrei Popescu; Shyam Habarakada
> Cc: Doug Turner; Chris Prince; Alec Berntson; Aaron Boodman; public-geolocation@w3c.org
> Subject: RE: skeleton Geolocation API
> Hi everyone.
> This is a little bit of a different issue and may add color to the
> discussion regarding optional vs. required: what are all the possible
> errors we are considering?
> Would timeouts be part of it?
> Thanks.
> Chris
Received on Monday, 28 July 2008 20:43:44 UTC

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