Handling Errors

Errors in workflow rules can and do happen for a number of reasons which include:

• Database or network problems
• Data conflicts between concurrent users
• Resource conflicts such as locked files or network sockets
• Insufficient Java process memory
• Programming errors.

If an error occurs in one of the Web Central classes, such as DataSource, the class method will throw an ExceptionBase instance. If an error occurs in your code, it may be thrown as any Java exception object, including runtime (unchecked) exception such as NullPointerException .

The simplest and best exception handling technique is: do not handle exceptions unless you have to. This means that WFR methods typically should not use try/catch/finally blocks and leave the exception handling to Web Central. The Web Central workflow rule container will catch all exceptions, checked or unchecked, and handle them as follows:

• Roll back the current database transaction
• Log the exception to archibus.log
• Format and localize the error message based on the exception information
• Return the error message and detailed information to the client JavaScript code.

If you do need to implement custom exception handling, follow these rules:

• Do not "swallow" exceptions without actually handling them. The following code is dangerous because it catches all exceptions and does not re-throw them, creating an illusion of correct execution. Neither the user, nor the IT personnel will have any idea that something went wrong:

try {
        // do something
} catch (Throwable t) {
        // silently ignore any errors 
}

• Re-throw exceptions after handling them, so that the workflow rule container can do its part. It is preferable to throw ExceptionBase instances, since they carry additional information used by the container. The following pattern can be useful:

try {
        // do something
} catch (ExceptionBase eb) {
        // do custom exception handling
        // re-throw the same exception
        throw eb;

} catch (Throwable originalException) {
        // do custom exception handling

        // supply your user-friendly error message
        // @translatable
        String message = "My custom message";
        
        // throw ExceptionBase but nest the original exception inside
        throw new ExceptionBase(null, message, originalException);
}

• If the custom exception handling code is the same or similar in many workflow rules, put this code in a helper method and call it from these workflow rules.

} catch (Throwable t) {
        handleException(t);
}

// somewhere in the same event-handler class, or in a helper class:

protected static void handleException(Throwable t) throws ExceptionBase {
        // do custom exception handling
        
        // @translatable
        String message = "My custom message";
        throw new ExceptionBase(null, message, t);
}