+Exceptions are a great mecanism to deal with error exception, everyone knows
+that.
+
+Without exceptions, you have to rely on returning a value indicating whether
+the function call were right or not, and check the return values of every
+single function you call. If there is one point in the calling sequence
+where your forgot this check, the chain is broken and caller won't notice
+the issue. In practice, dealing with error without exceptions loads user
+code with *tons* of those stupid checks and you loose your functional code
+in the middle of that miasm.
+
+With them, you simply write your code. If you want to deal with errors (ie,
+you actually know how to react to errors at this point of your code), you
+write a catching block. If you don't, you don't. And exceptions flow through
+from trowing point to catching point without bothering you.
+
+At this point, you may be a bit surprised by the previous paragraphs.
+SimGrid and GRAS are written in C, and everybody knows that there is no
+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).
+
+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
+within the library as we are than if we could change the compiler itself to
+add some extra checks here and specific treatment there. But it is also a
+advantage for us, since the exception mecanism is perfectly fitted to the
+distributed settings of GRAS processes. They can easily propagate on the
+net, as we will see in the next lesson (\ref GRAS_tut_tour_rpc) and contain
+information about the host on which they were thrown (#xbt_ex_t) along with
+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
+
+Then, you simply add a #TRY/#CATCH block around your code:
+\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.
+
+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.
+Moreover, the error messages and symptom can get <b>really crude</b> when
+misusing the exceptions.
+
+ - <b>Do not move out of a TRY block with a return, a break or any other
+ kind of jump. NEVER. EVER.</b>. This is the most tempting error, and this
+ drives the system nuts. You will probably segfault in the next exception
+ raising, far away from where you incidentally typed <tt>return</tt>
+ (this is because there is some cleanups to do at the end of a TRY block,
+ you cannot just leave it).
+ - <b>Play safe with variables modified in the TRY block</b>. You may want
+ to mark them as <tt>volatile</tt>, which is a modifier (just like
+ <tt>const</tt>) indicating that the value of the denoted variable may get
+ changed by external parts of the program during the run. This is the case
+ when your data gets modified by an exception raising function, I guess.
+
+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.
+