devn00b
/
EQ2EMu


			
							12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
							<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Exceptions - Boost.Outcome documentation</title>
<link rel="stylesheet" href="../css/boost.css" type="text/css">
<meta name="generator" content="Hugo 0.52 with Boostdoc theme">
<meta name="viewport" content="width=device-width,initial-scale=1.0"/>

<link rel="icon" href="../images/favicon.ico" type="image/ico"/>
<body><div class="spirit-nav">
<a accesskey="p" href="../motivation.html"><img src="../images/prev.png" alt="Prev"></a>
    <a accesskey="u" href="../motivation.html"><img src="../images/up.png" alt="Up"></a>
    <a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="../motivation/errno.html"><img src="../images/next.png" alt="Next"></a></div><div id="content">
  <div class="titlepage"><div><div><h1 style="clear: both">Exceptions</h1></div></div></div>
  

<p>Exceptions are the default mechanism in C++ for reporting, propagating and
processing the information about function failures. Their main advantage is
the ability to describe the &ldquo;success dependency&rdquo; between functions: if you want to
say that calling function <code>g()</code> depends on the successful execution of function <code>f()</code>,
you just put <code>g()</code> below <code>f()</code> and that&rsquo;s it:</p>
<div class="highlight"><pre class="chroma"><code class="language-c++" data-lang="c++"><span class="kt">int</span> <span class="nf">a</span><span class="p">()</span>
<span class="p">{</span>
  <span class="n">f</span><span class="p">();</span>
  <span class="n">g</span><span class="p">();</span>        <span class="c1">// don&#39;t call g() and further if f() fails
</span><span class="c1"></span>  <span class="k">return</span> <span class="n">h</span><span class="p">();</span> <span class="c1">// don&#39;t call h() if g() fails
</span><span class="c1"></span><span class="p">}</span>
</code></pre></div>
<p>In the C++ Standard terms this means that <code>f()</code> is <em>sequenced before</em> <code>g()</code>.
This makes failure handling extremely easy: in a lot of cases you do not have
to do anything.</p>

<p>Also, while next operations are being canceled, the exception object containing
the information about the initial failure is kept on the side. When at some point
the cancellation cascade is stopped by an exception handler, the exception object
can be inspected. It can contain arbitrarily big amount of data about the failure
reason, including the entire call stack.</p>

<h3 id="downsides">Downsides</h3>

<p>There are two kinds of overheads caused by the exception handling mechanism. The
first is connected with storing the exceptions on the side. Stack unwinding works
independently in each thread of execution; each thread can be potentially handling
a number of exceptions (even though only one exception can be active in one thread).
This requires being prepared for storing an arbitrary number of exceptions of arbitrary
types per thread. Additional things like jump tables also need to be stored in the
program binaries.</p>

<p>Second overhead is experienced when throwing an exception and trying to find the
handler. Since nearly any function can throw an exception of any time, this is
a dynamic memory allocation. The type of an exception is erased and a run-time type
identification (RTTI) is required to asses the type of the active exception object.
The worst case time required for matching exceptions against handlers cannot be easily
predicted and therefore exceptions are not suitable for real-time or low-latency
systems.</p>

<p>Another problem connected with exceptions is that while they are good for program
flows with linear &ldquo;success dependency&rdquo;, they become inconvenient in situations where
this success dependency does not occur. One such notable example is releasing acquired
resources which needs to be performed even if previous operations have failed.
Another example is when some function <code>c()</code> depends on the success of at least one
of two functions <code>a()</code> and <code>b()</code> (which try, for instance, to store user data by
two different means), another example is when implementing a strong exception safety
guarantee we may need to apply some fallback actions when previous operations have
failed. When failures are reported by exceptions, the semantics of canceling all
subsequent operations is a hindrance rather than help; these situations require special
and non-trivial idioms to be employed.</p>

<p>For these reasons in some projects using exceptions is forbidden. Compilers offer
switches to disable exceptions altogether (they refuse to compile a <code>throw</code>, and turn
already compiled <code>throw</code>s into calls to <code>std::abort()</code>).</p>


        </div><p><small>Last revised: March 22, 2019 at 13:58:05 -0700</small></p>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="../motivation.html"><img src="../images/prev.png" alt="Prev"></a>
    <a accesskey="u" href="../motivation.html"><img src="../images/up.png" alt="Up"></a>
    <a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="../motivation/errno.html"><img src="../images/next.png" alt="Next"></a></div></body>
</html>