Skip to content
This repository was archived by the owner on Oct 2, 2019. It is now read-only.
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

Open

Description

@efullea

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

Activity

  1. marcoscaceres commented on Jul 2, 2013

    @marcoscaceres
    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.

  2. efullea commented on Jul 3, 2013

    @efullea
    MemberAuthor

    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.

  3. marcoscaceres commented on Jul 3, 2013

    @marcoscaceres
    Contributor

    My favorite is SUCCESS_NO_ERROR ... error :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions