1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2<html><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 3<title>Exceptions - Boost.Outcome documentation</title> 4<link rel="stylesheet" href="../css/boost.css" type="text/css"> 5<meta name="generator" content="Hugo 0.52 with Boostdoc theme"> 6<meta name="viewport" content="width=device-width,initial-scale=1.0"/> 7 8<link rel="icon" href="../images/favicon.ico" type="image/ico"/> 9<body><div class="spirit-nav"> 10<a accesskey="p" href="../motivation.html"><img src="../images/prev.png" alt="Prev"></a> 11 <a accesskey="u" href="../motivation.html"><img src="../images/up.png" alt="Up"></a> 12 <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"> 13 <div class="titlepage"><div><div><h1 style="clear: both">Exceptions</h1></div></div></div> 14 15 16<p>Exceptions are the default mechanism in C++ for reporting, propagating and 17processing the information about function failures. Their main advantage is 18the ability to describe the “success dependency” between functions: if you want to 19say that calling function <code>g()</code> depends on the successful execution of function <code>f()</code>, 20you just put <code>g()</code> below <code>f()</code> and that’s it:</p> 21<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> 22<span class="p">{</span> 23 <span class="n">f</span><span class="p">();</span> 24 <span class="n">g</span><span class="p">();</span> <span class="c1">// don't call g() and further if f() fails 25</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 26</span><span class="c1"></span><span class="p">}</span> 27</code></pre></div> 28<p>In the C++ Standard terms this means that <code>f()</code> is <em>sequenced before</em> <code>g()</code>. 29This makes failure handling extremely easy: in a lot of cases you do not have 30to do anything.</p> 31 32<p>Also, while next operations are being canceled, the exception object containing 33the information about the initial failure is kept on the side. When at some point 34the cancellation cascade is stopped by an exception handler, the exception object 35can be inspected. It can contain arbitrarily big amount of data about the failure 36reason, including the entire call stack.</p> 37 38<h3 id="downsides">Downsides</h3> 39 40<p>There are two kinds of overheads caused by the exception handling mechanism. The 41first is connected with storing the exceptions on the side. Stack unwinding works 42independently in each thread of execution; each thread can be potentially handling 43a number of exceptions (even though only one exception can be active in one thread). 44This requires being prepared for storing an arbitrary number of exceptions of arbitrary 45types per thread. Additional things like jump tables also need to be stored in the 46program binaries.</p> 47 48<p>Second overhead is experienced when throwing an exception and trying to find the 49handler. Since nearly any function can throw an exception of any time, this is 50a dynamic memory allocation. The type of an exception is erased and a run-time type 51identification (RTTI) is required to asses the type of the active exception object. 52The worst case time required for matching exceptions against handlers cannot be easily 53predicted and therefore exceptions are not suitable for real-time or low-latency 54systems.</p> 55 56<p>Another problem connected with exceptions is that while they are good for program 57flows with linear “success dependency”, they become inconvenient in situations where 58this success dependency does not occur. One such notable example is releasing acquired 59resources which needs to be performed even if previous operations have failed. 60Another example is when some function <code>c()</code> depends on the success of at least one 61of two functions <code>a()</code> and <code>b()</code> (which try, for instance, to store user data by 62two different means), another example is when implementing a strong exception safety 63guarantee we may need to apply some fallback actions when previous operations have 64failed. When failures are reported by exceptions, the semantics of canceling all 65subsequent operations is a hindrance rather than help; these situations require special 66and non-trivial idioms to be employed.</p> 67 68<p>For these reasons in some projects using exceptions is forbidden. Compilers offer 69switches to disable exceptions altogether (they refuse to compile a <code>throw</code>, and turn 70already compiled <code>throw</code>s into calls to <code>std::abort()</code>).</p> 71 72 73 </div><p><small>Last revised: March 22, 2019 at 13:58:05 -0700</small></p> 74<hr> 75<div class="spirit-nav"> 76<a accesskey="p" href="../motivation.html"><img src="../images/prev.png" alt="Prev"></a> 77 <a accesskey="u" href="../motivation.html"><img src="../images/up.png" alt="Up"></a> 78 <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> 79</html> 80
