Chapter 6 The Error Model
Overview
Now that you understand the basic use of SourcePro DB, it’s time to confront the things that can go wrong. Error handling can be a messy topic under the best of circumstances. Mixing client/server computing with assorted message formats from various vendors, who may offer incomplete support for C++ exceptions, makes it even more complex. The error model of the DB Interface Module aims to keep as many options as possible under your control, while providing sensible default behavior where your application does not take explicit action.
Let's begin our discussion of the error model with an example:
RWCString s; float f;
RWDBReader reader = anotherTable.reader();
while (reader()) {
reader >> s >> f;
// process s and f
}
What would happen if each row of anotherTable contained two strings, rather than a string and a float? Or if the database server crashed in the middle of the loop? Or if the application lacked permission to read anotherTable? The good news is that your application wouldn't crash because of one of these errors. Of course, your application still needs to know that an error occurred. With the DB Interface Module error model, there are three ways to provide this information:
• Check status. You could check the status of the reader after each extraction >> operation. As we'll see in the next section, an invalid operation on an object causes the status of the object to change. This approach is simple, but often leads to cluttered code.
• Install an error handler. When an object's status changes to a state other than ok, an error handler is invoked. The default error handler does nothing. You can provide your own error handler to trap any or all errors, or you can provide specific error handlers for specific objects. This centralizes your error handling, although you may find it difficult to write a sufficiently general error handler, and maintaining multiple error handlers can be a source of errors in itself.
• Use exceptions. Your installed error handler can simply throw an exception. Then you could put the example code into a try block and catch the exceptions you're interested in.
The following sections explain the advantages and disadvantages of these alternatives in detail. We have kept the design of the error model of the DB Interface Module as flexible as possible, to accommodate the different needs of different applications.