DrEcho Docs

ADRs

Client Exception Handling

ADR #9

Context:

Need some guidelines for UI exception handling.

Decision:

Standardize UI error handling for client exceptions to ensure consistency and improve the predictability of exception handling across the application.

Pros:

  • Enhances readability for users and developers.
  • Improves maintainability by standardizing UI error handling.

Cons:

  • No immediate need for refactoring, but improving older classes would be beneficial.

Status: Accepted -> In progress


Additional Content

Implementation

  • GeneralUiException Class: Implement a GeneralUiException class responsible for handling localized error messages. This centralized approach ensures consistent handling of errors across the application and simplifies maintenance.

  • SomeSpecificException Class: Developers are required to create specific exception classes extending GeneralUiException. These classes should hardcode error header and content message keys as private fields (e.g., e.000.header, e.000.msg) AND provide a second method for more specific cases.

Example of use:

// Check...
if (true) {
    logger.error("[VM] Patient, performer and registrant cannot be null!");
    throw new VisitVmConfirmationException(); //or pass header and message
}

// Catch...
} catch (VisitVmConfirmationException ve) {
    ExceptionAlert alert = ExceptionAlert.create();
    alert.showError(ve, ve.getHeader(), ve.getContent());
}