Validation and Exception HandlingCST's way of handling errors occurring in the system was designed to meet three design goals:
- to support automated testing
- to promote graceful error recovery
- to safeguard sensitive information
An application's approach for managing errors can be as much an aspect of design as it is a sub-system. Careful consideration has been given both to where errors should and could be generated, and where they should be handled.
ValidationThere are three kinds of validation which are supported in CST:
- validation of record fields
- validation of record membership
- validation of imported record data
Figure Validation-1 shows that validation code used to support these activities resides in different parts of the design:
Validation of record fields is a task which belongs to the
Business Concept Layer of the architecture and is mainly handled by the method
TrialActivityModel.validate(...). The method is responsible for performing the following checks on a single instance of
- checks that all date field values are valid dates
- checks that in the sequence of date field values for an activity, populated fields are not preceeded by blank ones.
- check that the sequence of date field values are in non-descending chronological order
The last two checks can be disabled for a given activity through settings made in the configuration file.
TrialActivityModel only validates properties of a single instance of an activity record. Validating record membership is an activity that depends on the system knowing about all the records that exist in the data repository.
Implementations of LoggingServiceAPI and
AdminServiceAPI are responsible for checking for non-existent and duplicate records. These checks are applied in different operations. Checks for non-existent records are made prior to executing update and delete commands. They are also used in methods such as
validateUser(...) to check whether a given user exists in a list of registered users.
Checks for duplicate records are done before records are added to the repository.
The remaining validation activity is validating imported record data. This task is supported by I/O sub-systems used in the Administration and Logging Tools. Importing data from spreadsheets is a semi-automated activity which uses a sequence of GUIs to specify how data should be imported and an engine for parsing data from the files. It is a task which straddles presentation and business concept layers.
Where possible, validation checks are performed within the code used to support service implementations. Therefore, most validation will appear either in the Business Concept Layer or the Data Persistence Layer.
In the design, the GUI forms used in both tools may be regarded as exemplar software clients which make use of the service APIs. In future, web applications, web-services and command-line applications could use the services as well. In the interest of providing uniform security features for all deployments and re-using code, validation routines were kept out of the Presentation Layer.
Validation routines are usually used in the first few lines of methods used in service implementations. They are part of guard clauses that protect the main method body from illegal values passed as actual parameters.
Exception HandlingThe main classes used to handle exception handling in CST are shown below:
CST uses a checked exception called CSTException for two purposes:
- to express errors detected by validation routines
- to repackage data produced by other exceptions that come from other Java libraries
For example, when
ProductionLoggingToolQueries executes SQL queries, it may encounter an
SQLException. The exception may contain a message which could either be confusing to an end-user or reveal sensitive data. To avoid these problems, the class
SQLExceptions and throws instances of
CSTException which have more appropriate error messages.
CSTException will contain at least one
CSTError. Each error in turn comprises an error message for people and an error code for automated test cases.
The automated test cases use methods in
CSTException to obtain the total number of errors and the number of errors of a given type (see
Author: Kevin Garwood