DbC-DEM

The following macros are an approximation to implement a Disciplined Exception Mechanism using only the language preprocessor. More...

Macros
#define	rescue_retry
	To place at the beginning of the code to be retried.
#define	rescue_begin
	To place at the beginning of the rescue code.
#define	rescue_end
	To place at the end of the rescue code.
#define	retry
	Jump to the beginning of the code to be retried (must be inside the rescue code!).

Detailed Description

The following macros are an approximation to implement a Disciplined Exception Mechanism using only the language preprocessor.

Unlike the usual try/catch exception mechanism to handle errors, a Disciplined Exception Mechanism (DbC-DEP) follows a much simpler approach: It implements the idea that, in a DbC approach, a function (or method) can only succeed, by fully observing its contract, or fail; no other behavior is acceptable. Thus, a function only returns if it succeeds (observing its contract). In the presence of a failure, it launches an exception. Recovering from a failure is only possible if a function can fulfill its contract in a new attempt (using a different algorithm, or any other convenint way).

This perspective simplifies tremendously error handling solving two very serious problems with common try-catch exception mechanisms:

• First, the possibility to ignore an error, simply not putting the error handling defensive code, or put it in a way, that ignores the failure (such as catch an exception and do nothing with it).
• Second, using exceptions types to differentiate errors, ignoring the fact that the meaning of an exception type quickly vanishes away in the function call stack (usually if only meaningful in the direct client). (For a deeper analysis of these problems, using Java as an example language, see Contract-java: Design by contract in java with safe error handling, section 4).

However, in the DbC-DEP a failed function causes the failure of the client function, and so on, until, if required, a rescue is attempted. A rescue never compromises the function/module contract, as it allows only a retry to fulfill the contract (probably by using a different approach, or in a function which prescribes a weaker contract for an alternative acceptable behavior).

Example:

#include <dbc.h>
...
void redundant_function_with_two_alternative_implementations(...)
{
   require (..., "..."); // precondition
 
   int algorithm = 1;
   rescue_retry;
   switch(algorithm)
   {
      case 1:
         ...
         break;
      case 2:
         ...
         break;
   }
 
   ensure (..., "..."); // postcondition
 
   rescue_begin
      algorithm++;
      if (algorithm <= 2)
         retry
   rescue_end
}

Since exceptions are necessary here, these macros are only applicable in C++ (with EXCEPTION_POLICY macro defined), not in C (for a C approach see c-dbc library).

By default, rescue clause only catches DbC errors (DbC_Error*). This behavior can be modified to catch all types of exceptions be defining the compiling macro CATCH_ALL.