- \ref GRAS_tut_tour_exceptions_intro
- \ref GRAS_tut_tour_exceptions_use
- \ref GRAS_tut_tour_exceptions_recap
-
+
<hr>
\section GRAS_tut_tour_exceptions_intro Introduction
exception in C but only in C++, Java and such. This is true, exceptions are
not part of the C language, but this is such a great tool that we
implemented an exception mecanism as part of the SimGrid library (with
-setjmp and longjmp, for the curious).
+setjmp and longjmp, for the curious).
Being "home-grown" make our exception mecanic both stronger and weaker at
the same time. First it is weaker because, well, we are more limitated
the thrown point in the source code.
The syntax of XBT exceptions should not sound unfamilliar to most of you.
-You throw them using the #THROW0...#THROW7 macros. They take 2 extra
-arguments in addition to the format and its self arguments: an error
-category (of type #xbt_errcat_t) and an error "value" (an integer;
-pratically, this is often left to 0 in my own code). So, you may have
-something like the following:
-\verbatim THROW3(system_error, 0, "Cannot connect to %s:%d because of %s", hostname, port, reason);\endverbatim
+You throw them using the #THROW and #THROWF macros. They take 2 arguments:
+an error category (of type #xbt_errcat_t) and an error "value" (an integer;
+pratically, this is often left to 0 in my own code). #THROWF also takes a
+message string as extra argument which is a printf-like format string with
+its own arguments. So, you may have something like the following:
+\verbatim THROWF(system_error, 0, "Cannot connect to %s:%d because of %s", hostname, port, reason);\endverbatim
Then, you simply add a #TRY/#CATCH block around your code:
-\verbatim TRY{
- /* your code */
-} CATCH(e) {
+\verbatim TRY{
+ /* your code */
+}
+CATCH(e) {
/* error handling code */
} \endverbatim
Another strange thing is that you should actually free the memory allocated
to the exception with xbt_ex_fres() if you manage to deal with them. There
-is a bit more than this on the picture (#CLEANUP blocks, for example), and
-you should check the section \ref XBT_ex for more details.
+is a bit more than this on the picture (#TRY_CLEANUP blocks, for example), and
+you should check the section \ref XBT_ex for more details.
You should be <b>very carfull</b> when using the exceptions. They work great
when used correctly, but there is a few golden rules you should never break.
So, as you can see, you don't want to include large sections of your program
in TRY blocks. If you do so, it's quite sure that one day, you'll do a break
or a return within this block. And believe me, finding such typos is a real
-pain.
+pain.
If you are suspecting this kind of error, I made a little script for you:
check <tt>tools/xbt_exception_checker</tt> from the CVS. Given a set of C
like a JVM would do (ok, it'a a bit cruder than the one of the JVM, but
anyway). For each function frame of the calling stack, it displays the
function name and its location in the source files (if it manage to retrieve
-it). Don't be jalous, you can display such stacks wherever you want with
+it). Don't be jalous, you can display such stacks wherever you want with
xbt_backtrace_display() ;)
Unfortunately, this feature is only offered under Linux for now since I have
\include 08-exceptions.c
-Go to \ref GRAS_tut_tour_rpc
+Go to \ref GRAS_tut_tour_simpledata
*/
