Home • Corporate • Contacts •

TETware Java API Overview

Products

Solutions

Information

Datasheet

Documentation

FAQ

Knowledgebase

7. Error Handling and Reporting

Introduction

When an exception occurs in an API method in the TET package, the method throws a TetException object. This object contains fields and methods that provide information about the condition that caused the error to occur. Items that only apply to a particular method are described in the section that describes the method. Items that apply to all methods are described in the subsections that follow.

It is recommended that API exceptions are caught by test purposes and appropriate messages written to the journal. If an unhandled exception occurs in a test purpose function, the API catches the exception, prints a message to the journal and registers an UNRESOLVED result. If an unhandled exception occurs in a test case's startup method, the API cancels all the test purpose functions.

Classes in the TET package indicate fatal errors by throwing instances of subclasses of java.lang.Error. A test purpose either should not catch these objects or, if it does, the catching function should re-throw the error so that the API can catch it and perform the correct actions before terminating with the appropriate exit status.

In addition to the following fields and methods, the toString() method of TetException may be used in the usual way for Throwable objects; that is: to retrieve the message that describes the reason for the exception.

Contents:      tet_errno      tet_errlist()

tet_errno

      // public class TetException
      public int tet_errno;

The value of the tet_errno field in a TetException object indicates the reason why the exception was thrown. Distributed TETware uses a client/server architecture and calls to several of the API functions cause the API to send requests to server processes. A server sends a reply code in response to each request that it receives. When the reply code indicates that a request has failed, the value stored in tet_errno is derived from the server reply code. A list of the server reply codes and their meanings is presented in the appendix entitled "Server reply codes" in the TETware User Guide.

The possible error codes values are defined in the TestSession class as public static final fields, whose names and meanings are as follows:

     TET_ER_2BIG           Argument list too long.
     TET_ER_ABORT          Abort TCM on TP end.
     TET_ER_CONTEXT        Request out of context.
     TET_ER_DONE           Event finished or already happened.
     TET_ER_DUPS           Request contained duplicate IDs.
     TET_ER_ERR            General error code.
     TET_ER_FID            Bad identifier in file i/o request.
     TET_ER_FORK           Can't fork.
     TET_ER_INPROGRESS     Event in progress.
     TET_ER_INTERN         Server internal error.
     TET_ER_INVAL          Invalid parameter.
     TET_ER_LOGON          Not logged on to server.
     TET_ER_MAGIC          Bad magic number in server request.
     TET_ER_NOENT          No such file or directory.
     TET_ER_PERM           Privilege request/kill error.
     TET_ER_PID            No such process.
     TET_ER_RCVERR         Receive message error.
     TET_ER_REQ            Unknown request code.
     TET_ER_SIGNUM         Bad signal number.
     TET_ER_SNID           Bad sync identifier in SYNCD request.
     TET_ER_SYNCERR        Sync completed unsuccessfully.
     TET_ER_SYSID          System identifier not in system name list.
     TET_ER_TIMEDOUT       Request or system call timed out.
     TET_ER_TRACE          Tracing not configured.
     TET_ER_WAIT           Process not yet terminated.
     TET_ER_XRID           Bad execution results file identifier in XRESD request.

Whenever an unsuccessful API call throws a TetException with tet_errno set to TET_ER_ERR (the general error code), a diagnostic message is generated somewhere which contains more precise details of the cause of the error. If an error of this type occurs in the API library, the diagnostic is printed to the execution results file as a TCM/API message if possible; if this is not possible, the diagnostic is printed on the test case's standard error stream.

However, in Distributed TETware, an error of this type can also occur in a server process. In this case the more detailed error message is printed on the server's standard error stream. The result of this is that when an API call is unsuccessful in Distributed TETware and tet_errno is set to TET_ER_ERR, the more detailed error message often appears in a TCCD log file on the local system or on one of the remote systems that is participating in the test run.

tet_errlist()

      // public class TestSession
      public String[] tet_errlist()