Skip to content
This repository has been archived by the owner on Oct 2, 2019. It is now read-only.

Add More Error Codes When Failing to Send SMS/MMS #71

Open
efullea opened this issue Jul 2, 2013 · 3 comments
Open

Add More Error Codes When Failing to Send SMS/MMS #71

efullea opened this issue Jul 2, 2013 · 3 comments

Comments

@efullea
Copy link
Member

efullea commented Jul 2, 2013

Feedback from Mozilla's implementation experience:

Please see [8] and [9]. The current W3C doesn't define what the error codes
are going to be returned by the Future object. In Mozilla (we still use DOM
Request for now), we define the following error codes at [10] which is also
listed as below:

const unsigned short SUCCESS_NO_ERROR = 0;
const unsigned short NO_SIGNAL_ERROR = 1;
const unsigned short NOT_FOUND_ERROR = 2;
const unsigned short UNKNOWN_ERROR = 3;
const unsigned short INTERNAL_ERROR = 4;
const unsigned short NO_SIM_CARD_ERROR = 5;
const unsigned short RADIO_DISABLED_ERROR = 6;
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=885652
[9] https://bugzilla.mozilla.org/show_bug.cgi?id=880561
[10] http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/interfaces/nsIMobileMessageCallback.idl#24

@marcoscaceres
Copy link
Contributor

All these need to be refactored as DOMErrors. The errors will need to match errors in the Error Names Table, and the message attribute will need to be used to provide the information like "radio is disabled", etc.

@efullea
Copy link
Member Author

efullea commented Jul 3, 2013

comment from @jmcanterafonseca :

const unsigned short INTERNAL_ERROR = 4;

Unknown error and internal error seem to be the same

const unsigned short NO_SIM_CARD_ERROR = 5;

I think here we would need to be more generic, maybe we can use something
like SUBSCRIPTION_ERROR

const unsigned short RADIO_DISABLED_ERROR = 6;

This error seems to be similar to nosignal error. I believe we should not
try to generate too many error states as later will be harder to check for
compliance and interoperability, provided that there could be
implementations not able to report errors with such a precision.

@marcoscaceres
Copy link
Contributor

My favorite is SUCCESS_NO_ERROR ... error :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants