- 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