Detailed Description

An Exception indicate an error condition from which recovery may be possible.

The Library raise exceptions, which can be handled by recovery code, if recovery is possible. When an exception is raised, it is handled by the handler that was most recently instantiated. If no handlers are defined an exception will cause the library to call its abort handler to abort with an error message.

Handlers are instantiated by the TRY-CATCH and TRY-FINALLY statements, which are implemented as macros in this interface. These statements handle nested exceptions and manage exception-state data. The syntax of the TRY-CATCH statement is,

TRY
     S
CATCH(e1)
     S1
CATCH(e2)
     S2
[...]
CATCH(en)
     Sn
END_TRY;

The TRY-CATCH statement establish handlers for the exceptions named e1, e2,.., en and execute the statements S. If no exceptions are raised by S, the handlers are dismantled and execution continues at the statement after the END_TRY. If S raises an exception e which is one of e1..en the execution of S is interrupted and control transfers immediately to the statements following the relevant CATCH clause. If S raises an exception that is not one of e1..en, the exception will raise up the call-stack and unless a previous installed handler catch the exception, it will cause the application to abort.

Here's a concrete example calling a method in the libzdb API which may throw an exception. If the method Connection_execute() fails it will throw an SQLException. The CATCH statement will catch this exception, if thrown, and log an error message

TRY
     [...]
     Connection_execute(c, sql);
CATCH(SQLException)
     log("SQL error: %s\n", Connection_getLastError(c)); 
END_TRY;

The TRY-FINALLY statement is similar to TRY-CATCH but in addition adds a FINALLY clausal which is always executed, regardless if an exception was raised or not. The syntax of the TRY-FINALLY statement is,

TRY
     S
CATCH(e1)
     S1
CATCH(e2)
     S2
     [...]
CATCH(en)
     Sn
FINALLY
     Sf
END_TRY;

<p<blockquote>‍

Note that Sf is executed whether S raise an exception or not. One purpose of the TRY-FINALLY statement is to give clients an opportunity to "clean up" when an exception occurs. For example,

TRY
{
     [...]
     Connection_execute(c, sql);
}
FINALLY
{
     Connection_close(c);
}
END_TRY;

closes the database Connection regardless if an exception was thrown or not by the code in the TRY-block. The above example also demonstrate that FINALLY can be used without an exception handler, if an exception was thrown it will be rethrown after the control reaches the end of the finally block. Meaning that we can cleanup even if an exception was thrown and the exception will automatically propagate up the call stack afterwards.

Finally, the RETURN statement, defined in this interface, must be used instead of C return statements inside a try-block. If any of the statements in a try block must do a return, they must do so with this macro instead of the usual C return statement.

Exception details

Inside an exception handler, details about an exception is available in the variable Exception_frame. The following demonstrate usage of this variable to provide detailed logging of an exception. For SQL errors, Connection_getLastError() can also be used, though Exception_frame is recommended since in addition to SQL errors, it also cover API errors not directly related to SQL.

TRY 
{
     code that can throw an exception
}
ELSE  
{
     fprintf(stderr, "%s: %s raised in %s at %s:%d\n",
             Exception_frame.exception->name, 
             Exception_frame.message, 
             Exception_frame.func, 
             Exception_frame.file,
             Exception_frame.line);
     ....
}
END_TRY;

Volatile and assignment inside a try-block

A variable declared outside a try-block and assigned a value inside said block should be declared volatile if the variable will be accessed from an exception handler. Otherwise the compiler will/may optimize away the value set in the try-block and the handler will not see the new value. Declaring the variable volatile is only necessary if the variable is to be used inside a CATCH or ELSE block. Example:

volatile int i = 0;
TRY
{
 i = 1; 
 <throw SQLException>
}
CATCH(SQLException)
{
    assert(i == 1); // Unless declared volatile i would be 0 here (implementation dependent)
}
END_TRY;
assert(i == 1); // i will be 1 here regardless if it is declared volatile or not

Thread-safe

The Exception stack is stored in a thread-specific variable so Exceptions are made thread-safe. This means that Exceptions are thread local and an Exception thrown in one thread cannot be catched in another thread. This also means that clients must handle Exceptions per thread and cannot use one TRY-ELSE block in the main program to catch all Exceptions. This is only possible if no threads were started.

This implementation is a minor modification of the Except code found in David R. Hanson's excellent book C Interfaces and Implementations.

See also: SQLException.h

Macros
#define	T Exception_T

#define	THROW(e, cause, ...)
	Throws an exception. More...

#define	RETHROW
	Re-throws an exception. More...

#define	RETURN
	Clients must use this macro instead of C return statements inside a try-block. More...

#define	TRY
	Defines a block of code that can potentially throw an exception. More...

#define	CATCH(e)
	Defines a block containing code for handling an exception thrown in the TRY block. More...

#define	ELSE
	Defines a block containing code for handling any exception thrown in the TRY block. More...

#define	FINALLY
	Defines a block of code that is subsequently executed whether an exception is thrown or not. More...

#define	END_TRY
	Ends a TRY-CATCH block. More...

Macro Definition Documentation

◆ T

#define T Exception_T

◆ THROW

#define THROW	(	e,
		cause,
		...
	)

Throws an exception.

Parameters

e	The Exception to throw
cause	The cause. A NULL value is permitted, and indicates that the cause is unknown.

◆ RETHROW

#define RETHROW

Re-throws an exception.

In a CATCH or ELSE block clients can use RETHROW to re-throw the Exception

◆ RETURN

#define RETURN

Clients must use this macro instead of C return statements inside a try-block.

◆ TRY

#define TRY

Defines a block of code that can potentially throw an exception.

◆ CATCH

#define CATCH ( e )

Defines a block containing code for handling an exception thrown in the TRY block.

Parameters

e	The Exception to handle

◆ ELSE

#define ELSE

Defines a block containing code for handling any exception thrown in the TRY block.

An ELSE block catches any exception type not already catched in a previous CATCH block.

◆ FINALLY

#define FINALLY

Defines a block of code that is subsequently executed whether an exception is thrown or not.

◆ END_TRY

#define END_TRY

Ends a TRY-CATCH block.