[SERVER-10276] Clarify mutable BSON error handling and invariant checking Created: 21/Jul/13 Updated: 02/Aug/18 Resolved: 25/Jul/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.2 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
Mutable BSON mostly uses Status codes to return errors upstream, however there are some open questions about what to do for cases where this is not possible, or for which the error indicates a fundamental abuse of the API (e.g. calling a method on a non-OK Element, which is arguably much like dereferencing an invalid shared pointer). Currently, these fundamental cases are handled with 'verify', but this is not ideal, as verify a) can't be tested, and b) doesn't provide much context. We need to determine whether these verify calls should be masserts, dasserts, fasserts, or removed. |
| Comments |
| Comment by auto [ 25/Jul/13 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: |