Use Case

As a Node driver user and developer
I want a consistent convention for errors returned by the driver
So that the code is easier to debug and understand

Dependencies

• None

Unknowns

• questions that need to be answered to determine implementation

Acceptance Criteria

• Review error class implementations done by the other drivers (start with Swift, but loo at the others, too)
• Focusing on MongoDriverError, create an extension hierarchy that helps categorize the errors in a clear and consistent manner (e.g., separating validation errors from runtime errors)
  • Identify cases where the same error messages are used and map them to the same error class to eliminate code duplication
  • Think of use cases from the perspective of writing an application that uses the driver
  • Potential examples:
    • MongoAuthError
    • MongoLogicError (to warn developers about incorrect usage)
    • MongoBSONError (three kinds: serialization due to user error, deserialization due to server sending a bad document response, BSON library bug preventing valid serialization/deserialization)
• Capture finalized documentation structure in docs/errors.md; use the format in the official mongo spec repo as a base
• Write a test plan identifying what needs to be covered, include constructor unit test coverage
• Have the node team review and approve the error design
• Create new jira tickets breaking down the implementation of the new classes into parts

Implementation Requirements

• Think about the implications that changing the class names will have on the code base; call out potential risks or breaking changes

Testing Requirements

• Test plan only

Documentation Requirements

• None

Follow Up Requirements

• Implementation tickets following design