+/** @addtogroup XBT_ex
+ *
+ * This module is a small ISO-C++ style exception handling library
+ * for use in the ISO-C language. It allows you to use the paradigm
+ * of throwing and catching exceptions in order to reduce the amount
+ * of error handling code without hindering program robustness.
+ *
+ * This is achieved by directly transferring exceptional return codes
+ * (and the program control flow) from the location where the exception
+ * is raised (throw point) to the location where it is handled (catch
+ * point) -- usually from a deeply nested sub-routine to a parent
+ * routine. All intermediate routines no longer have to make sure that
+ * the exceptional return codes from sub-routines are correctly passed
+ * back to the parent.
+ *
+ * These features are brought to you by a modified version of the libex
+ * library, one of the numerous masterpiece of Ralf S. Engelschall.
+ *
+ * @section XBT_ex_intro DESCRIPTION
+ *
+ * In SimGrid, exceptions is a triple <\a msg , \a category , \a value>
+ * where \a msg is a human-readable text describing the exceptional
+ * condition, \a code an integer describing what went wrong and \a value
+ * providing a sort of sub-category. (this is different in the original libex).
+ *
+ * @section XBT_ex_base BASIC USAGE
+ *
+ * \em xbt_try \b TRIED_BLOCK [\em xbt_cleanup \b CLEANUP_BLOCK] \em xbt_catch (variable) \b CATCH_BLOCK
+ *
+ * This is the primary syntactical construct provided. It is modeled after the
+ * ISO-C++ try-catch clause and should sound familiar to most of you.
+ *
+ * Any exception thrown directly from the TRIED_BLOCK block or from called
+ * subroutines is caught. Cleanups which must be done after this block
+ * (whenever an exception arised or not) should be placed into the optionnal
+ * CLEANUP_BLOCK. The code dealing with the exceptions when they arise should
+ * be placed into the (mandatory) CATCH_BLOCK.
+ *
+ *
+ * In absence of exception, the control flow goes into the blocks TRIED_BLOCK
+ * and CLEANUP_BLOCK (if present); The CATCH_BLOCK block is then ignored.
+ *
+ * When an exception is thrown, the control flow goes through the following
+ * blocks: TRIED_BLOCK (up to the statement throwing the exception),
+ * CLEANUP_BLOCK (if any) and CATCH_BLOCK. The exception is stored in a
+ * variable for inspection inside the CATCH_BLOCK. This variable must be
+ * declared in the outter scope, but its value is only valid within the
+ * CATCH_BLOCK block.
+ *
+ * Some notes:
+ * - xbt_try, xbt_cleanup and xbt_catch cannot be used separately, they work
+ * only in combination and form a language clause as a whole.
+ * - In contrast to the syntax of other languages (such as C++ or Jave) there
+ * is only one xbt_catch block and not multiple ones (all exceptions are
+ * of the same C type xbt_t).
+ * - the variable of xbt_catch can naturally be reused in subsequent
+ * xbt_catch clauses.
+ * - it is possible to nest xbt_try clauses.
+ *
+ * The xbt_try block is a regular ISO-C language statement block, but it is not
+ * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
+ * "return", "goto" or longjmp(3) because there is some hidden setup and
+ * cleanup that needs to be done regardless of whether an exception is
+ * caught. Bypassing these steps will break the exception handling facility.
+ *
+ * The xbt_cleanup and xbt_catch blocks are regular ISO-C language statement
+ * blocks without any restrictions. You are even allowed to throw (and in the
+ * xbt_catch block to re-throw) exceptions.
+ *
+ * There is one subtle detail you should remember about xbt_try blocks:
+ * Variables used in the xbt_cleanup or xbt_catch clauses must be declared with
+ * the storage class "volatile", otherwise they might contain outdated
+ * information if an exception it thrown.
+ *
+ *
+ * This is because you usually do not know which commands in the xbt_try
+ * were already successful before the exception was thrown (logically speaking)
+ * and because the underlying ISO-C setjmp(3) facility applies those
+ * restrictions (technically speaking). As a matter of fact, value changes
+ * between the xbt_try and the xbt_throw may be discarded if you forget the
+ * "volatile" keyword.
+ *
+ * @section XBT_ex_advanced ADVANCED USAGE
+ *
+ * @subsection xbt_defer DEFERING_BLOCK XBT_ex_defer
+ *
+ * This directive executes DEFERING_BLOCK while deferring the throwing of
+ * exceptions, i.e., exceptions thrown within this block are remembered, but
+ * the control flow still continues until the end of the block. At its end, the
+ * first exception which occured within the block (if any) is rethrown (any
+ * subsequent exceptions are ignored).
+ *
+ * DEFERING_BLOCK is a regular ISO-C language statement block, but it is not
+ * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
+ * "return", "goto" or longjmp(3). It is however allowed to nest xbt_defer
+ * clauses.
+ *
+ * @subsection XBT_ex_shield xbt_shield SHIELDED_BLOCK
+ *
+ * This directive executes SHIELDED_BLOCK while shielding it against the
+ * throwing of exceptions, i.e., any exception thrown from this block or its
+ * subroutines are silently ignored.
+ *
+ * SHIELDED_BLOCK is a regular ISO-C language statement block, but it is not
+ * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
+ * "return", "goto" or longjmp(3). It is however allowed to nest xbt_shield
+ * clauses.
+ *
+ * @subsection XBT_ex_conditions Retrieving the current execution condition
+ *
+ * \a xbt_catching, \a xbt_deferred and \a xbt_shielding return a boolean
+ * indicating whether the current scope is within a TRYIED_BLOCK,
+ * DEFERING_BLOCK and SHIELDED_BLOCK (respectively)
+ *
+ * \section XBT_ex_pitfalls PROGRAMMING PITFALLS
+ *
+ * Exception handling is a very elegant and efficient way of dealing with
+ * exceptional situation. Nevertheless it requires additional discipline in
+ * programming and there are a few pitfalls one must be aware of. Look the
+ * following code which shows some pitfalls and contains many errors (assuming
+ * a mallocex() function which throws an exception if malloc(3) fails):
+ *
+ * \dontinclude ex_test.c
+ * \skip BAD_EXAMPLE
+ * \until end_of_bad_example
+ *
+ * This example raises a few issues:
+ * -# \b variable \b scope \n
+ * Variables which are used in the xbt_cleanup or xbt_catch clauses must be
+ * declared before the xbt_try clause, otherwise they only exist inside the
+ * xbt_try block. In the example above, cp1, cp2 and cp3 only exist in the
+ * xbt_try block and are invisible from the xbt_cleanup and xbt_catch
+ * blocks.
+ * -# \b variable \b initialization \n
+ * Variables which are used in the xbt_cleanup or xbt_catch clauses must
+ * be initialized before the point of the first possible xbt_throw is
+ * reached. In the example above, xbt_cleanup would have trouble using cp3
+ * if mallocex() throws a exception when allocating a TOOBIG buffer.
+ * -# \b volatile \b variable \n
+ * Variables which are used in the xbt_cleanup or xbt_catch clauses MUST BE
+ * DECLARED AS "volatile", otherwise they might contain outdated
+ * information when an exception is thrown.
+ * -# \b clean \b before \b catch \n
+ * The xbt_cleanup clause is not only place before the xbt_catch clause in
+ * the source code, it also occures before in the control flow. So,
+ * resources being cleaned up cannot be used in the xbt_catch block. In the
+ * example, c3 gets freed before the printf placed in xbt_catch.
+ * -# \b variable \b uninitialization \n
+ * If resources are passed out of the scope of the
+ * xbt_try/xbt_cleanup/xbt_catch construct, they naturally shouldn't get
+ * cleaned up. The example above does free(3) cp1 in xbt_cleanup although
+ * its value was affected to globalcontext->first, invalidating this
+ * pointer.
+
+ * The following is fixed version of the code (annotated with the pitfall items
+ * for reference):
+ *
+ * \skip GOOD_EXAMPLE
+ * \until end_of_good_example
+ *
+ * @{
+ */
