Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-3363

Design a consistent error naming convention, hierarchy, and structure

    • Type: Icon: Task Task
    • Resolution: Done
    • Priority: Icon: Unknown Unknown
    • None
    • Affects Version/s: None
    • Component/s: None
    • Not Needed

      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

            Assignee:
            neal.beeken@mongodb.com Neal Beeken
            Reporter:
            daria.pardue@mongodb.com Daria Pardue
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: