Custom Error Reporting

It is possible that a plug-in performs the operations exactly as you require, but you need to customize the error reporting. One area of the Cúram application where this may happen is in the pre-validation operation when the pattern matching option is applied. A pattern is a regular expression defined in the UML model. When this validation fails, the error reports that the data was "not in a recognized format", as few users would be able to interpret the meaning of a regular expression if presented to them. If the format is a common and intuitive one (a phone number, say), then this message will probably suffice. However, if the format is more obscure, the error message may need to be changed to present a human-readable description of the format (correctly localized). There are two ways to achieve this:

A custom validation is possible and you will just need to follow the usual guidelines for such a customization, but it is complicated by the need to access the pattern information and perform the pattern matching operation. As you would then need to report your custom error message, it is much simpler to let the existing infrastructure do all the pattern matching and just focus on the error message.

Custom error reporting is really only applicable to the parse and preValidate methods of a converter plug-in. These are the only methods that may be invoked and passed values that a user has entered and that a user may be able to correct in response to an error message. The converter plug-ins supplied with the out-of-the-box Cúram application do not report any errors from their validate methods, so, unless you want to customize another custom converter plug-in, the validate method can be ignored.

  1. Identify the method that is generating the exception that carries the error message that you want to customize. The likely candidates are the converter plug-in's parse and preValidate methods.
  2. Create a new sub-class of the relevant converter plug-in and override the appropriate method.
  3. In the implementation of the method, invoke the super-class's method of the same name and catch any exception thrown.
  4. Test the error number on the caught exception to ensure it is the one you want to override.
  5. If the error number is correct, throw a new exception carrying your error message, otherwise, re-throw the caught exception, as it is not the one you wish to override.
  6. Configure your new plug-in for the relevant domains.

This example shows how this might be done to override the pattern match failure message. The custom exception class described in Custom Exception Classes is used.

Figure 1. Custom Error Reporting
/**
 * Reports that social security numbers must match the format
 * "xxx-xx-xxxx" when the regular expression defined in the
 * UML model "\d{3}\-\d{2}\-\d{4}" does not match a social
 * security number entered by a user.
 */
public class SSNConverter
       extends SvrStringConverter {
  public void preValidate(Object data)
         throws ConversionException {
    try {
      super.preValidate(data);
    } catch (ConversionException e) {
      if (e.getMessageObject().getMessageID()
          == e.ERR_CONV_NO_MATCH) {
        throw new CustomConversionException(-200001);
      }
      throw e;
    }
  }
}

The error message entry in the custom message catalog will look like this:

Figure 2. Custom Pattern Match Failure Message
-200001=ERROR: The field '%0s' must use the format 'xxx-xx-xxxx'.

Domains that require this converter can be configured in the same manner as shown for the other converters above.

When using the error messages interception, please keep in mind, that Cúram error messages are subject to change without notice. However, in the specific case of the pattern match failure message, the error -122128 - ERR_CONV_NO_MATCH will be preserved, as the possible need to intercept this message is recognized.