Unless you elect to put all your error handling inline, you will find it necessary to design one or more error handlers for your DB Interface Module applications. So far, we have deliberately kept our example error handling routines extremely simple, in order to concentrate on presenting an overview of the error model. In this section, we go into the subject in more detail.

6.5.1 Kinds of Errors

The first thing a useful error handler needs to know is what kind of error it is dealing with. The Essential Tools Module approach is to classify errors as internal or external, depending on whether or not they can reasonably be predicted in advance by the programmer. In the Essential Tools Module, an internal error throws an exception of type RWInternalError, and an external error throws an exception of type RWExternalError. In the DB Interface Module, however, database errors are also possible. To simplify the situation, we have adopted the policy that all errors are external errors. This means that:

6.5.2 Capturing Database-Dependent Information

Table 8: RWDBStatus contents for Oracle errors

Table 9: RWDBStatus contents for Sybase Open Client Client-Library (and CS-Library) errors

Table 10: RWDBStatus contents for Microsoft SQL Server errors

You can see in these tables that the layouts are similar but not identical. This is not surprising, since error reporting is not standardized well among database APIs. Let us now return and modify our error handler to cope with this problem:

void errorHandler(const RWDBStatus& s) { switch(s.errorCode()) { case RWDBStatus::serverError: cout << s.message() << endl << "Error number: " << s.vendorError1() << endl << "Server: " << s.vendorMessage1() << endl << "Severity: " << s.vendorError2() << endl; break; case RWDBStatus::serverMessage: case RWDBStatus::vendorLib: // handle other database errors default: // raise an exception if (!status.isValid()) { s.raise(); } } }

Now let's create an error condition. The following fragment attempts to drop a database table that doesn't exist:

RWDBTable junk = myDbase.table("junk");//table doesn't exist RWDBStatus s = junk.drop();

On our system, this is the output when the example is run against an Oracle database and a Sybase database, respectively:

(Oracle output)

[SERVERERROR] ORA-00942: table or view does not exist Error number: 942 Server:

(Sybase output)

[SERVERERROR] Cannot drop the table 'junk', because it doesn't exist in the system catalogs. Error number: 3701 Server: SYBASE100 Severity: 11

Now suppose that your application needs to take some special action if a table doesn't exist. Evidently your application must be able to interpret database errors, not just report them, and to interpret them it must recognize the database. Perhaps the most straightforward way for your application to handle different databases, then, is to have separate error handlers for each database type:

const long OraNoTableError = 942; const long SybNoTableError = 3701; void oraErrorHandler(const RWDBStatus& s) { RWDBStatus::ErrorCode code = s.errorCode(); if (code == RWDBStatus::serverError && s.vendorError1() == OraNoTableError) { // take special action } else { s.raise(); } } void sybErrorHandler(const RWDBStatus& s) { RWDBStatus::ErrorCode code = s.errorCode(); if (code == RWDBStatus::serverError && s.vendorError1() == SybNoTableError) { // take special action } else { s.raise(); } } . . . RWDBDatabase oracle = RWDBManager::database ( /*args for Oracle*/ ); RWDBDatabase sybase = RWDBManager::database ( /*args for Sybase*/ ); oracle.setErrorHandler(oraErrorHandler); sybase.setErrorHandler(sybErrorHandler);

When the database-dependent table does not exist error comes up, it is trapped explicitly and handled by the take special action case in the appropriate error handler. The trade-off here is between portability and specificity. The more portable your application, the less database-dependent intelligence it can use, and vice versa.