There are several different types of assertions used in the MongoDB code. In brief:
When per-operation invariant checks fail, the current operation fails, but the process and connection persist. This means that massert, uassert and verify only terminate the current operation, not the whole process. Be careful not to corrupt process state by mistakenly using these assertions midway through mutating process state. Examples of this include uassert and massert inside of constructors and destructors. fassert failures will terminate the entire process; this is used for low-level checks where continuing might lead to corrupt data or loss of data on disk.
Both massert and uassert take error codes, so that all errors have codes associated with them. These error codes are assigned incrementally; the numbers have no meaning other than a way to associate a log message with a line of code. scons checks for duplicates, but if you want the next available code you can run:
A failed operation-fatal assertion throws an AssertionException or a child of that. The inheritance hierarchy is something like:
Generally, code in the server should be prepared to catch a DBException. UserAssertionException’s are particularly common as errors and should be expected. We use resource acquisition is initialization heavily.
Gotchas to watch out for: