80 lines
5.3 KiB
HTML
80 lines
5.3 KiB
HTML
<!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>
|