Websphere commerce Command error handling

Here we are going to discuss types of exceptions that a command can throw, how the exceptions are handled, how message text is stored and used, how the exceptions are logged, and how to use the provided framework in your own commands.

Types of exceptions

A command can throw one of the following exceptions:

ECApplicationException

This exception is thrown if the error is related to user input and will always fail. For example, when a user enters an invalid parameter, an ECApplicationException is thrown. When this exception is thrown, the solution controller does not retry the command, even if it is specified as a retriable command.

ECSystemException

This exception is thrown if a runtime exception or a WebSphere Commerce configuration error is detected. Examples of this type of exception include create exceptions, remote exceptions, and other EJB exceptions. When this type of exception is thrown, the solution controller retries the command if the command is retriable.

In order to throw one of these exceptions, the following information must be specified:

Error view name

The view that will be used to display the error. For Web requests, the Web controller looks up this name in the Struts configuration files.

ECMessage object

ECMessage defines the static information related to the reason for the exception. This value corresponds to the message text contained within a properties file.

ECParameter

ECParameter returns the errors associated with the application. The exception can indicate multiple errors since each part of an application exception represent an error.

Error parameters

These name-value pairs are used to substitute information into the error message. For example, a message may contain a parameter to hold the name of the method which threw the exception. This parameter is set when the exception is thrown, then when the error message is logged, the log file contains the actual method name.

Error data

These are optional attributes that can be made available to the JSP page through the error data bean.

Exception handling in customized code

When creating new commands, it is important to include appropriate exception handling. 

Writing your own exception handling logic, involves the following steps:

1. Catching the exceptions in your command that require special processing.
2. Constructing either an ECApplicationException or ECSystemException, based upon the type of exception caught.
3. If the ECApplicationException uses a new message, defining the message in a new properties file.

Catching and constructing exceptions

To illustrate the first two steps, the following code snippet shows an example of catching a system exception within a command:

try {
// your business logic
}
catch(FinderException e) {
     throw new ECSystemException (ECMessage._ERR_FINDER_EXCEPTION, 
          className, methodName, new Object [] {e.toString()}, e); 
}

The preceding _ERR_FINDER_EXCEPTION ECMessage object is defined as follows:

public static final ECMessage _ERR_FINDER_EXCEPTION = 
new ECMessage (ECMessageSeverity.ERROR, ECMessageType.SYSTEM, 
     ECMessageKey._ERR_FINDER_EXCEPTION);

The _ERR_FINDER_EXCEPTION message text is defined within the ecServerMessages_xx_XX.properties file (where _xx_XX is a locale indicator such as _en_US), as follows:

_ERR_FINDER_EXCEPTION  = 
     The following Finder Exception occurred during processing: "{0}".

When catching a system exception, there is a predefined set of messages that can be used. These are described in the following table:

Message Object	Description
_ERR_FINDER_EXCEPTION	Thrown when an error is returned from an EJB finder method call.
_ERR_REMOTE_EXCEPTION	Thrown when an error is returned from an EJB remote method call.
_ERR_CREATE_EXCEPTION	Thrown when an error occurs creating an EJB instance.
_ERR_NAMING_EXCEPTION	Thrown when an error is returned from the name server.
_ERR_GENERIC	Thrown when an unexpected system error occurs. For example, a null pointer exception.

When catching an application exception, you can either use an existing message that is specified in the appropriate error message properties file, or create a new message that is stored in a new properties file. As specified previously, you must not modify any of the predefined error message properties files.

The following code snippet shows an example of catching an application exception within a command:

try {
// your business logic

}
// catch some new type of application exception
catch(//your new exception)
 {
     throw new ECApplicationException (MyMessages._ERR_CUSTOMER_INVALID, 
          className, methodName, errorTaskName, someNVPs); 
}

The preceding _ERR_CUSTOMER_INVALID ECMessage object is defined as follows:

public static final ECMessage _ERR_CUSTOMER_INVALID = 
     new ECMessage (ECMessageSeverity.ERROR, ECMessageType.USER, 
     MyMessagesKey._ERR_CUSTOMER_INVALID, "ecCustomerMessages");

When constructing new user messages, you should assign them with a type of USER, as follows:

ECMessageType.USER

The text for the _ERR_CUSTOMER_INVALID message is contained in the ecCustomerMessages.properties file. This file must reside in a directory that is in the class path. The text is defined as follows:

_ERR_CUSTOMER_INVALID = Invalid ID "{0}"

 Refrence : Command error handling