Fall 2017

CSc 560: Database Systems Implementation

Error Reporting

A layered approach is used to error reporting, but the path that error discovery takes may be confusing at times since the calling sequence between layers can be complex (e.g., DB->BufMgr->DSM).

Each layer of the database has associated with it a list of errors that can occur. Character strings with messages corresponding to these errors are stored in arrays. These arrays are registered to the global error object minibase_errors by constructing an error_string_table using the array. Each layer is responsible for establishing and registering it's error string array.

A global error class is used to log errors as they occur. When an error is discovered, the following actions are performed:

Push the name of the layer in which the execution is currently in. For example, suppose the error was discovered by the buffer manager after a call to a function of the DB manager, the buffer manager pushes BufMgr on the error stack.
Push the offset into the array (for that class) of error messages.
Push a string with some context sensitive information about the error. This information includes the name of the file and the line number in the file where this error discovery has occured.

This elaborate protocol allows the user to see where the error was first discovered and to see how the error caused various functions to fail. Error correction can also be done if desired by popping errors from the stack and correcting the error.

Design Decisions

Macros disguise the details of this protocol. MINIBASE_FIRST_ERROR is called to register the "first" error. For example, if the HeapFile sees that the length of a (new) record to be updated is different than that of the (old) record, the HeapFile posts an INVALID_UPDATE error as :

MINIBASE_FIRST_ERROR( HEAPFILE, INVALID_UPDATE );

As another example, if the buffer manager detects that the buffer pool is too full to complete a certain operation, it posts a BUFFEREXCEEDED error as :

MINIBASE_FIRST_ERROR( BUFMGR, BUFFEREXCEEDED );

The MINIBASE_CHAIN_ERROR macro is called for "chained" error. For example, if the HeapFile calls on the buffer manager to (un)pin a page in buffer pool, and that operation fails, the HeapFile adds an error that records the fact that the execution path that failed went through it:

status = MINIBASE_BM->(un)pinPage( ... );
if ( status != OK )
    return MINIBASE_CHAIN_ERROR( HEAPFILE, status );

Or, if the buffer manager calls on the database manager to write a page to disk, and that operation fails, the buffer manager adds an error that records the fact that the execution path that failed went through it:

status = MINIBASE_DB->write_page( ... );
if ( status != OK )
    return MINIBASE_CHAIN_ERROR( BUFMGR, status );

Sometimes, you wish to post a different error message, but still acknowledge that the error resulted from a prior error. This is a combination of the above situations. For this, use the MINIBASE_RESULTING_ERROR macro:

status = MINIBASE_DB->write_page( ... );
if ( status != OK ) 
	 return MINIBASE_RESULTING_ERROR( BUFMGR, status, BUFFEREXCEEDED )

Click here for the error interface. (Includes extensive in-line documentation.)

Back to the List of Components
Back to the Minibase Home Page