- 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>
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 UTC