-
Type: Task
-
Resolution: Done
-
Priority: Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
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
- is depended on by
-
NODE-3399 Implement error hierarchy laid out in in docs/errors.md
- Closed