sysapps / messaging

The messaging API
4 stars 7 forks source link

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

Open efullea opened 11 years ago

efullea commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

My favorite is SUCCESS_NO_ERROR ... error :)