INFORMIX
Informix-ESQL/C Programmer's Manual
Chapter 11: Exception Handling
Home Contents Index Master Index New Book

Choosing an Exception-Handling Strategy

By default, an ESQL/C application does not perform any exception handling for SQL statements. Therefore, unless you explicitly provide such code, execution continues when an exception occurs. While this behavior might not be too serious for successful execution, warnings, and NOT FOUND conditions, it can have very serious consequences in the event of a runtime error.

A runtime error might halt the program execution. Unless you check for and handle these errors in the application code, this behavior can cause the end user great confusion and annoyance. It also can leave the application in an inconsistent state.

Within an ESQL/C application, choose a consistent strategy for exception handling. You can choose one of the following exception-handling strategies:

Important: Consider how to perform exception handling in an application before you begin development so that you take a consistent and maintainable approach.

Checking After Each SQL Statement

To check for an exception, you can include code to explicitly test the value of SQLSTATE (or SQLCODE).

Tip: Decide whether to use SQLSTATE (and the diagnostics area) or SQLCODE (and the sqlca structure) to determine exception values. Use the chosen exception-handling variables consistently. If you mix these two variables unnecessarily, you create code that is difficult to maintain. Keep in mind that SQLSTATE is the more flexible and portable of these two options.
For example, if you want to use SQLSTATE to check whether a CREATE DATABASE statement has executed as expected, you can use the code that Figure 11-18 shows.

Figure 11-18
Using SQLSTATE to Test Whether an Error Occurred During an SQL Statement

As an alternative, you can write an exception-handling function that processes any exception. Your program can then call this single exception-handling function after each SQL statement.

The sqlstate_exception() function, which Figure 11-19 shows, is an example of an exception-handling function that uses the SQLSTATE variable and the diagnostics area to check for warnings, the NOT FOUND condition, and runtime errors. It is designed to be called after each SQL statement.

Figure 11-19
Example of an Exception-Handling Function That Uses SQLSTATE

The sqlstate_exception() function, which Figure 11-19 shows, handles exceptions as follows:

To handle errors, the sqlstate_exception() function could alternatively omit the exit() call and allow execution to continue. In this case, the function must return the SQLSTATE or SQLCODE (for Informix-specific errors) value so the calling program can determine what action to take for a runtime error.

The WHENEVER Statement

You can use the WHENEVER statement to trap for exceptions that occur during the execution of SQL statements. The WHENEVER statement provides the following information:

WIN NT/95
    Do not use the WHENEVER ERROR STOP construction in an ESQL/C program that you want to compile as a DLL.

If no WHENEVER statement exists for a given condition, the ESQL/C preprocessor uses CONTINUE as the default action. To execute the sqlstate_exception() function (shown in Figure 11-19) every time an error occurs, you can use the GOTO action of the WHENEVER SQLERROR statement. If you specify the SQLERROR condition of WHENEVER, you obtain the same behavior as if you check the SQLCODE or SQLSTATE variable for an error after each SQL statement.

The WHENEVER statement for the GOTO action can take the following two forms:

With the GOTO action, your program automatically transfers control to the error_label label when the SQL statement generates an exception. When you use the GOTO label action of the WHENEVER statement, your code must contain the label and appropriate logic to handle the error condition. In the following example, the logic at label is simply a call to the sqlstate_exception() function:

You must define this error_label label in each program block that contains SQL statements. If your program contains more than one function, you might need to include the error_label label and code in each function. Otherwise, the preprocessor generates an error when it reaches the function that does not contain the error_label. It tries to insert the code that the WHENEVER...GOTO statement has requested, but the function has not defined the error_label label.

To remove the preprocessor error, you can put the labeled statement with the same label name in each function, you can issue another action for the WHENEVER statement to reset the error condition, or you can replace the GOTO action with the CALL action to call a separate function.

You can also use the CALL keyword in the WHENEVER statement to call the sqlstate_exception() function when errors occur. (The CALL option is an Informix extension to the ANSI standard.)

If you want to call the sqlstate_exception() function every time an SQL error occurs in the program, take the following steps:

Tip: In the preceding code fragment, you do not include the parentheses after the sqlstate_exception() function.
Make sure, however, that all functions that the WHENEVER...CALL affects can find a declaration of the sqlstate_exception() function. For details of the syntax and how to use the WHENEVER statement, see the Informix Guide to SQL: Syntax.




Informix-ESQL/C Programmer's Manual, version 9.1
Copyright © 1998, Informix Software, Inc. All rights reserved.