blob: 68b216ec87feca0b4ad98be122f7c91257ef6674 [file] [log] [blame]
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en' lang='en'>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8'/>
<title>frequently asked questions</title>
<link href='reno.css' type='text/css' rel='stylesheet'/>
</head>
<body>
<div class="body-0">
<div class="body-1">
<div class="body-2">
<div>
<div id="boost_logo">
<a href="http://www.boost.org"><img style="border:0" src="../../../boost.png" alt="Boost" width="277" height="86"/></a>
</div>
<h1>Boost Exception</h1>
</div>
<!-- Copyright (c) 2006-2009 Emil Dotchevski and Reverge Studios, Inc. -->
<!-- Distributed under the Boost Software License, Version 1.0. (See accompanying -->
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
<div class="RenoIncludeDIV"><div class="RenoAutoDIV"><h2>Frequently Asked Questions</h2>
</div>
<h3>Why doesn't boost::exception derive from std::exception?</h3>
<p>Despite that <span class="RenoLink"><a href="using_virtual_inheritance_in_exception_types.html">virtual inheritance should be used in deriving from base exception types</a></span>, many programmers fail to follow this principle when deriving from std::exception. If boost::<span class="RenoLink"><a href="exception.html">exception</a></span> derives from std::exception, using the <span class="RenoLink"><a href="enable_error_info.html">enable_error_info</a></span> function with such user-defined types would introduce dangerous ambiguity which would break all catch(std::exception &amp;) statements.</p>
<p>Of course, boost::<span class="RenoLink"><a href="exception.html">exception</a></span> should not be used to replace std::exception as a base type in exception type hierarchies. Instead, it should be included as a virtual base, in addition to std::exception (which should also be derived virtually.)</p>
<h3>Why is boost::exception abstract?</h3>
<p>To prevent exception-neutral contexts from erroneously erasing the type of the original exception when adding <span class="RenoLink"><a href="error_info.html">error_info</a></span> to an active exception object:</p>
<pre>catch( boost::<span class="RenoLink"><a href="exception.html">exception</a></span> &amp; e )
{
e <span class="RenoLink"><a href="exception_operator_shl.html">&lt;&lt;</a></span> foo_info(foo);
throw e; //Compile error: boost::<span class="RenoLink"><a href="exception.html">exception</a></span> is abstract
}</pre>
<p>The correct code is:</p>
<pre>catch( boost::<span class="RenoLink"><a href="exception.html">exception</a></span> &amp; e )
{
e <span class="RenoLink"><a href="exception_operator_shl.html">&lt;&lt;</a></span> foo_info(foo);
throw; //Okay, re-throwing the original exception object.
}</pre>
<h3>What is the space overhead of the boost::exception base class?</h3>
<p>The space overhead for the boost::exception data members is negligible in the context of exception handling. Throwing objects that derive from boost::<span class="RenoLink"><a href="exception.html">exception</a></span> does not by itself cause dynamic memory allocations.</p>
<p>Deriving from boost::<span class="RenoLink"><a href="exception.html">exception</a></span> enables any data to be added to exceptions, which usually does allocate memory. However, this memory is reclaimed when the exception has been handled, and since typically user code does not allocate memory during the unrolling of the stack, adding error info to exceptions should not cause memory fragmentation.</p>
<h3>Should I use boost::throw_exception or BOOST_THROW_EXCEPTION or just throw?</h3>
<p>The benefit of calling boost::<span class="RenoLink"><a href="throw_exception.html">throw_exception</a></span> instead of using throw directly is that it ensures that the emitted exception derives from boost::<span class="RenoLink"><a href="exception.html">exception</a></span> and that it is compatible with boost::<span class="RenoLink"><a href="current_exception.html">current_exception</a></span>.</p>
<p>The <span class="RenoLink"><a href="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> macro also results in a call to boost::<span class="RenoLink"><a href="throw_exception.html">throw_exception</a></span>, but in addition it records in the exception object the __FILE__ and __LINE__ of the throw, as well as the pretty name of the function that throws. This has virtually no overhead, yet enables boost::<span class="RenoLink"><a href="diagnostic_information.html">diagnostic_information</a></span> to compose a more useful, if not user-friendly message.</p>
<p>Typical use of boost::<span class="RenoLink"><a href="diagnostic_information.html">diagnostic_information</a></span> is:</p>
<pre>catch( boost::exception &amp; e )
{
std::cerr &lt;&lt; "OMG!" &lt;&lt; boost::diagnostic_information(e);
}
catch( ... )
{
std::cerr &lt;&lt; "OMG!!!";
}</pre>
<p>This is a possible message it may display, the first line is only possible if <span class="RenoLink"><a href="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> is used:</p>
<pre>example_io.cpp(70): Throw in function class boost::shared_ptr&lt;struct _iobuf&gt; __cdecl my_fopen(const char *,const char *)
Dynamic exception type: class boost::exception_detail::clone_impl&lt;class fopen_error&gt;
std::exception::what: example_io error
[struct boost::<span class="RenoLink"><a href="errinfo_api_function.html">errinfo_api_function</a></span>_ *] = fopen
[struct boost::<span class="RenoLink"><a href="errinfo_errno.html">errinfo_errno</a></span>_ *] = 2, "No such file or directory"
[struct boost::<span class="RenoLink"><a href="errinfo_file_name.html">errinfo_file_name</a></span>_ *] = tmp1.txt
[struct boost::<span class="RenoLink"><a href="errinfo_file_open_mode.html">errinfo_file_open_mode</a></span>_ *] = rb</pre>
<h3>Why is boost::exception integrated in boost::throw_exception?</h3>
<p>The boost::<span class="RenoLink"><a href="throw_exception.html">throw_exception</a></span> function predates the Boost Exception library and there has been some concern about its current behavior of injecting boost::<span class="RenoLink"><a href="exception.html">exception</a></span> as a base of any exception passed to boost::<span class="RenoLink"><a href="throw_exception.html">throw_exception</a></span>. Such concerns are dictated by the typical strict interpretation of a common principle in C and C++, that users only pay for features they actually use.</p>
<p>The problem is that users of Boost Exception can't by themselves cause a library to throw types that derive from boost::<span class="RenoLink"><a href="exception.html">exception</a></span>, and without this they can't use any of the Boost Exception facilities.</p>
<p>For example, if a user wants to use Boost Serialization in a separate thread, it is desirable to be able to transport exceptions emitted by that library into the main thread where they can be analyzed to generate a user-friendly message. This can be easily achieved using boost::<span class="RenoLink"><a href="exception_ptr.html">exception_ptr</a></span>, but this requires that Boost Serialization throws exceptions using boost::<span class="RenoLink"><a href="enable_current_exception.html">enable_current_exception</a></span>. If Boost Serialization calls boost::<span class="RenoLink"><a href="throw_exception.html">throw_exception</a></span> to throw, this behavior happens automatically and transparently.</p>
<p>The cost of this integration is:</p>
<div><ul><li> In terms of space: a pointer and 3 ints are added to the static size of exception objects.</li>
<li> In terms of speed: the pointer is initialized to null at the point of the throw.</li>
<li> In terms of coupling: about 400 self-contained lines of C++ with no external includes.</li>
</ul></div>
<h3>Why use operator&lt;&lt; overload for adding info to exceptions?</h3>
<p>Before throwing an object of type that derives from boost::<span class="RenoLink"><a href="exception.html">exception</a></span>, it is often desirable to add one or more <span class="RenoLink"><a href="error_info.html">error_info</a></span> objects in it. The syntactic sugar provided by <span class="RenoLink"><a href="exception_operator_shl.html">exception/operator&lt;&lt;</a></span> allows this to be done directly in a throw expression:</p>
<pre>throw error() <span class="RenoLink"><a href="exception_operator_shl.html">&lt;&lt;</a></span> foo_info(foo) <span class="RenoLink"><a href="exception_operator_shl.html">&lt;&lt;</a></span> bar_info(bar);</pre>
<p>which saves typing compared to this possible alternative:</p>
<pre>error e;
e.add(foo_info(foo));
e.add(bar_info(bar));
throw e;</pre>
<p>and looks better than something like:</p>
<pre>throw error().add(foo_info(foo)).add(bar_info(bar));</pre>
<h3>Why is operator&lt;&lt; allowed to throw?</h3>
<p>This question is referring to the following issue. Consider this throw statement example:</p>
<pre>throw file_open_error() <span class="RenoLink"><a href="exception_operator_shl.html">&lt;&lt;</a></span> file_name(fn);</pre>
<p>The intention here is to throw a file_open_error, however if <span class="RenoLink"><a href="exception_operator_shl.html">operator&lt;&lt;</a></span> fails to copy the std::string contained in the file_name <span class="RenoLink"><a href="error_info.html">error_info</a></span> wrapper, a std::bad_alloc could propagate instead. This behavior seems undesirable to some programmers.</p>
<p>Bjarne Stroustrup, The C++ Programming Language, 3rd Edition, page 371:</p>
<blockquote><p><i>"Throwing an exception requires an object to throw. A C++ implementation is required to have enough spare memory to be able to throw bad_alloc in case of memory exhaustion. However, it is possible that throwing some other exception will cause memory exhaustion."</i></p></blockquote>
<p>So, an attempt to throw any exception may already result in propagating std::bad_alloc instead.</p>
</div><div class="RenoAutoDIV"><div class="RenoHR"><hr/></div>
See also: <span class="RenoPageList"><a href="boost-exception.html">Boost Exception</a>&nbsp;| <a href="motivation.html">Motivation</a></span>
</div>
<!-- Copyright (c) 2006-2009 Emil Dotchevski and Reverge Studios, Inc. -->
<!-- Distributed under the Boost Software License, Version 1.0. (See accompanying -->
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
<div id="footer">
<p>
<a class="logo" href="http://jigsaw.w3.org/css-validator/check/referer"><img class="logo_pic" src="valid-css.png" alt="Valid CSS" height="31" width="88"/></a>
<a class="logo" href="http://validator.w3.org/check?uri=referer"><img class="logo_pic" src="valid-xhtml.png" alt="Valid XHTML 1.0" height="31" width="88"/></a>
<small>Copyright (c) 2006-2009 by Emil Dotchevski and Reverge Studios, Inc.<br/>
Distributed under the <a href="http://www.boost.org/LICENSE_1_0.txt">Boost Software License, Version 1.0</a>.</small>
</p>
</div>
</div>
</div>
</div>
</body>
</html>