You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 2, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 2, 2019. It is now read-only.
Add More Error Codes When Failing to Send SMS/MMS #71
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:
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.
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.
Activity
marcoscaceres commentedon Jul 2, 2013
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 commentedon Jul 3, 2013
comment from @jmcanterafonseca :
Unknown error and internal error seem to be the same
I think here we would need to be more generic, maybe we can use something
like SUBSCRIPTION_ERROR
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 commentedon Jul 3, 2013
My favorite is SUCCESS_NO_ERROR ... error :)