- * 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
- *
- * <center><b>it is not
- * allowed to jump into it via "goto" or longjmp(3) or out of it via "break",
- * "return", "goto" or longjmp(3)</b>.</center>
- *
- * This is 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 symptom are likely to be a segfault at the next exception raising point,
- * ie far away from the point where you did the mistake. If you suspect
- * that kind of error in your code, have a look at the little script
- * <tt>tools/xbt_exception_checker</tt> in the CVS. It extracts all the TRY
- * blocks from a set of C files you give it and display them (and only
- * them) on the standard output. You can then grep for the forbidden
- * keywords on that output.
- *
- * 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 is 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.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
- *
- * @{
- */
-
-/** @brief different kind of errors */
-typedef enum {
- unknown_error = 0, /**< unknown error */
- arg_error, /**< Invalid argument */
- bound_error, /**< Out of bounds 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 */
- cancel_error, /**< an action was canceled */
- thread_error, /**< error while [un]locking */
- host_error, /**< host failed */
- tracing_error, /**< error during the simulation tracing */
- io_error /**< disk or file error */
-} xbt_errcat_t;
-
-XBT_PUBLIC(const char *) xbt_ex_catname(xbt_errcat_t cat);
-
-/** @brief Structure describing an exception */
-typedef struct {
- char *msg; /**< human readable message */
- xbt_errcat_t category; /**< category like HTTP (what went wrong) */
- int value; /**< like errno (why did it went wrong) */
- /* throw point */
- char *procname; /**< Name of the process who thrown this */
- int pid; /**< PID of the process who thrown this */
- char *file; /**< Thrown point */
- int line; /**< Thrown point */
- char *func; /**< Thrown point */
- /* Backtrace */
- int used;
- char **bt_strings; /* only filed on display (or before the network propagation) */
- void *bt[XBT_BACKTRACE_SIZE];
-} xbt_ex_t;
-
-/* declare the running context type
- * (that's where we get the process name for the logs and the exception storage)
- * -- do not mess with it --