- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 6 Apr 2011 17:28:37 +0200
- To: public-device-apis@w3.org
Hi,
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