Page tree

Overview

Documents approaches to error handling.

Details

The overall strategy of the system is to capture errors in lower levels of the system and throw them up to an application layer that can actually do something useful with it.  In this case, that means handling errors at the REST service layer.   An error handler is used to process all exceptions by writing a stack trace to a log, sending email to a configured list of administrators, and sending either an HTTP code 401 or 500 back to the client with an appropriate error message depending upon whether it is an authentication/authorization failure or an application failure.

A sophisticated exception hierarchy is not leveraged.  Instead, most lower level calls merely throw Exception with the possibility that it is an application defined "LocalException".  The only difference here is that LocalExceptions are guaranteed to contain user friendly error messages and do not need a stack trace pushed to the log.  These are known conditions in the application that trigger errors that do not require additional layers of auditing or tracking.  An example of this is an attempt to log in with an incorrect username or password - in this case the user merely needs to be informed of the condition and admins do not need to respond.

Configuration

In order to have emails sent in response to application errors, a few properties must be configured in the config.properties file.

Property
Default Value
Notes
mail.enabledfalseBy default mail is disabled, this has to be specifically configured.
mail.smtp.usern/aThe login for the mail server
mail.smtp.fromn/aThe "from" user for emails sent by the system.
mail.smtp.passwordn/aThe user's mail server password
mail.smtp.hostn/a

The mail server host

mail.smtp.portn/aThe mail server port
mail.smtp.starttls.enablen/aA setting indicating that a TLS layer secures mail server communications
mail.smtp.authn/a

A setting indicating that mail requests should be authenticated

mail.smtp.to n/aThe list of users who should receive email upon errors.

 

NOTE: at the moment, the sending of email in the production deployment is specifically configured to support the IHTSDO style authenticated mail server.  Non-encrypted email configurations are also supported.

  • n/a

 

  • No labels