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 “success dependency” 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’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'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'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 “success dependency”, 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>
|