Closed Bug 1056918 Opened 6 years ago Closed 6 years ago

LoopContacts should allow distinguishing between 'not found' and 'database error' programmatically

Categories

(Hello (Loop) :: Client, defect)

defect
Not set
normal

Tracking

(firefox34 fixed)

RESOLVED FIXED
mozilla34
Tracking Status
firefox34 --- fixed

People

(Reporter: abr, Assigned: abr)

References

Details

Attachments

(1 file)

When a LoopContacts user attempts to retreive a contact, it should be able to
tell the difference between "that contact isn't in the database" and "an
attempt to access the database resulted in an exception or other error of some
kind" without examining error.message. Calling the callback with both "error"
and "contact" set to null conveys this unambiguously, and has the added
benefit of playing nicely with users who wrap the callback in a Promise.

(Semantically, this is sensical: "your search request succeeded, but did not
yield any results".)
Attachment #8476773 - Flags: review?(dmose)
Blocks: 972079
Attachment #8476773 - Flags: review?(dmose) → review?(standard8)
Comment on attachment 8476773 [details] [diff] [review]
Allow distinguishing between 'not found' and 'database error' programmatically

Review of attachment 8476773 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r=Standard8
Attachment #8476773 - Flags: review?(standard8) → review+
https://hg.mozilla.org/mozilla-central/rev/2b5bc470740d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Looks like this landed with tests. Does this need QA?
Whiteboard: [qa?]
Flags: qe-verify?
Whiteboard: [qa?]
Depends on: 1060812
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #5)
> Looks like this landed with tests. Does this need QA?

Probably not; this is just an API change, and the mochi tests check that the functional behavior is as expected.
Thanks Adam, untracked for verification.
Flags: qe-verify? → qe-verify-
QA Contact: anthony.s.hughes
You need to log in before you can comment on or make changes to this bug.