Project History

Use Cases Scenarios
Use Case Requirements
Bugs and Known Limitations

User Manuals Getting Started
General Tour
Configuration Options
Logging Tool Tour
Administration Tool Tour

Developers Architecture
Analysis of Design
Creating Plugins
Future Enhancements

Validation and Exception Handling

CST's way of handling errors occurring in the system was designed to meet three design goals:

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.


There are three kinds of validation which are supported in CST:

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 TrialActivityModel:

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 Handling

The main classes used to handle exception handling in CST are shown below:

CST uses a checked exception called CSTException for two purposes:

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 catches the SQLExceptions and throws instances of CSTException which have more appropriate error messages.

A 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 Automated Testing).

Author: Kevin Garwood

(c)2010 Medical Research Council. Licensed under Apache 2.0.