+
+/** @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 TRY \b TRIED_BLOCK [\em CLEANUP \b CLEANUP_BLOCK] \em 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:
+ * - TRY, CLEANUP and 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 CATCH block and not multiple ones (all exceptions are
+ * of the same \em xbt_ex_t C type).
+ * - the variable of CATCH can naturally be reused in subsequent
+ * CATCH clauses.
+ * - it is possible to nest TRY clauses.
+ *
+ * The 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 CLEANUP and CATCH blocks are regular ISO-C language statement
+ * blocks without any restrictions. You are even allowed to throw (and, in the
+ * CATCH block, to re-throw) exceptions.
+ *
+ * There is one subtle detail you should remember about TRY blocks:
+ * Variables used in the CLEANUP or 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 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 TRY and the THROW may be discarded if you forget the
+ * "volatile" keyword.
+ *
+ * \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 CLEANUP or CATCH clauses must be
+ * declared before the TRY clause, otherwise they only exist inside the
+ * TRY block. In the example above, cp1, cp2 and cp3 only exist in the
+ * TRY block and are invisible from the CLEANUP and CATCH
+ * blocks.
+ * -# \b variable \b initialization \n
+ * Variables which are used in the CLEANUP or CATCH clauses must
+ * be initialized before the point of the first possible THROW is
+ * reached. In the example above, 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 CLEANUP or 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 CLEANUP clause is not only place before the CATCH clause in
+ * the source code, it also occures before in the control flow. So,
+ * resources being cleaned up cannot be used in the CATCH block. In the
+ * example, c3 gets freed before the printf placed in CATCH.
+ * -# \b variable \b uninitialization \n
+ * If resources are passed out of the scope of the
+ * TRY/CLEANUP/CATCH construct, they naturally shouldn't get
+ * cleaned up. The example above does free(3) cp1 in 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
+ *
+ * @{
+ */
+
+typedef enum {
+ unknown_error=0, /**< unknown error */
+ arg_error, /**< Invalid argument */
+ mismatch_error, /**< The provided ID does not match */
+ not_found_error, /**< The searched element was not found */
+
+ system_error, /**< a syscall did fail */
+ network_error, /**< error while sending/receiving data */
+ timeout_error, /**< not quick enough, dude */
+ thread_error /**< error while [un]locking */
+} xbt_errcat_t;
+
+const char *xbt_errcat_name(xbt_errcat_t errcode);