Doing Error Handling for Operations

Designer 10.7 | webMethods Mobile Development | Code Snippets | Doing Error Handling for Operations

Each operation provides a response code as a protected member. The interpretation of this integer value depends on the operation type. Mobile Development uses this type to differentiate between RESTful operations (which inherit from AbstractRestOperation) and customized operations (which inherit from AbstractThreadedOperation). See also Creating Your Own Operation.

An AbstractRestOperation is meant as a super class for generated RESTful services. It opens an HTTP connection so that the response code can easily be compared with the HTTP result codes. The interface HTTPConnection lists all possible result codes for this kind of operation. It is recommended to use one IOperationDelegate for one HTTP result code. For a sample, see Chaining Multiple Operations.

An AbstractThreadedOperation is mostly used to encapsulate a single piece of business logic. Therefore, the response code must be set in its implementation class. Let us assume that you want to use a simple operation as described in Creating Your Own Operation. The recommended way is to introduce a set of public variables that can also be used to determine the result in an IOperationDelegate. If everything works correctly, you can simply set the protected member responseCode to OK. If an exception occurs, set the responseCode to the error and also throw the nested exception. Throwing the exception will force the operation to call onOperationFailed for each added IOperationDelegate.

public class MyOperation extends AbstractThreadedOperation {

public static int RESULT_OK = 1;

public static int RESULT_ERROR = 2;

protected void runInternal() throws Exception {
try {
// some logic in here
responseCode = RESULT_OK;
} catch(Exception e) {
responseCode = RESULT_ERROR;
throw e;
}
}
}