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());
}