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

RESOLVED FIXED in Firefox 34

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: abr, Assigned: abr)

Tracking

unspecified
mozilla34
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox34 fixed)

Details

Attachments

(1 attachment)

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: 5 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.