W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

Contact errors

From: Robin Berjon <robin@berjon.com>
Date: Wed, 6 Apr 2011 17:28:37 +0200
Message-Id: <FB5E52E5-9A14-4E42-812A-8795B50121D3@berjon.com>
To: public-device-apis@w3.org

some quick notes on the ContactError interface.

Do we know why there is an UNKNOWN_ERROR type? Do we expect it to ever happen? Can we test for it?

INVALID_ARGUMENT_ERROR should either be specified (in the algorithm that processes find()'s parameters) or dropped.

Are there actually conditions under which TIMEOUT_ERROR may occur? I think things just keep waiting. We could drop it.

When does an IO_ERROR happen? I think that it should be dropped.

When does NOT_SUPPORTED_ERROR happen? I think that it should be dropped.

I'd suggest replacing several of the above with an ADDRESS_BOOK_ERROR which encapsulates any error condition that the underlying address book system may have encountered and which makes it impossible for the operation to complete.

I know I've harped on this dead horse before, but can we move away from integer-based constants and use strings instead?

interface ContactError {
    const DOMString UNKNOWN_ERROR = "unknown";
    const DOMString INVALID_ARGUMENT_ERROR = "invalid argument";
    const DOMString TIMEOUT_ERROR = "timeout";
    const DOMString PENDING_OPERATION_ERROR = "pending operation";
    const DOMString IO_ERROR = "io";
    const DOMString NOT_SUPPORTED_ERROR = "not supported";
    const DOMString PERMISSION_DENIED_ERROR = "denied";
    readonly attribute DOMString code;

Or rather, applying the above clean up to the error codes:

interface ContactError {
    const DOMString PENDING_OPERATION_ERROR = "pending operation";
    const DOMString PERMISSION_DENIED_ERROR = "denied";
    const DOMString ADDRESS_BOOK_ERROR = "address book";
    readonly attribute DOMString code;

Robin Berjon - http://berjon.com/
Received on Wednesday, 6 April 2011 15:29:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:48 UTC