Design discussion: error handling and HTTP status codes

Description

This ticket is for a design discussion about standardizing our use of Exceptions and general error handling. This should include:

  • Sharing some of the articles about use of Exceptions (Josh had a specific example about the billion-dollar mistake)

  • Sharing example code about a pattern for error handling (Josh)

  • Then reviewing, perhaps in a screensharing meeting, to review this pattern and talk about any concerns (like concerns that this will cause lots of boilerplate code). It's possible a single meeting can address this, and then we document and share a decision with the group (such as on the dev list in google groups).

  • Summarize our decision in writing with a list of what kinds of situations should trigger which kinds of Exceptions and errors. EG:

    • Database cannot be reached -> Exception -> HTTP 500

    • User tries approving a Requisition that they do not have permissions to approve -> error handling -> HTTP 4__ and error message "123: You do not have permissions to approve this Requisition"

  • It's also possible this will turn into other tickets for assignments to implement a new pattern.

Josh and Jake and Pawel all have opinions on how we handle Exceptions and error codes, meaning HTTP response status code as well as a error message inside our response.

Examples in the current code that we want to reconsider:

  • Trying to retrieve a deleted requisition or trying to retrieve one that never existed (an ID that has never been used). Currently asking for a non-existent requisition ID appears to result in an exception being thrown and a 500 level event being returned. This user input should be handled properly, and a BAD REQUEST returned.

Note that includes a PDF document about standardized error handling.

Status

Assignee

Josh Zamor

Reporter

Brandon Bowersox-Johnson

Labels

None

Story Points

5

Components

Sprint

None

Fix versions

Priority

Critical