Validation and Exception Handling

CST'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.

Validation

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

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 Handling

The 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 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