<h3>Why use operator<< overload for adding info to exceptions?</h3>
<p>Before throwing an object of type that derives from boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span>, it is often desirable to add one or more <spanclass="RenoLink"><ahref="error_info.html">error_info</a></span> objects in it. The syntactic sugar provided by <spanclass="RenoLink"><ahref="exception_operator_shl.html">exception/operator<<</a></span> allows this to be done directly in a throw expression:</p>
<p>To prevent exception-neutral contexts from erroneously erasing the type of the original exception when adding <spanclass="RenoLink"><ahref="error_info.html">error_info</a></span> to an active exception object:</p>
<pre>catch( boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span>& e )
{
e <spanclass="RenoLink"><ahref="exception_operator_shl.html"><<</a></span> foo_info(foo);
throw e; //Compile error: boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> is abstract
}</pre>
<p>The correct code is:</p>
<pre>catch( boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span>& e )
{
e <spanclass="RenoLink"><ahref="exception_operator_shl.html"><<</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::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> does not by itself cause dynamic memory allocations.</p>
<p>Deriving from boost::<spanclass="RenoLink"><ahref="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>Why is boost::exception integrated in boost::throw_exception?</h3>
<p>The boost::<spanclass="RenoLink"><ahref="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::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> as a base of any exception passed to boost::<spanclass="RenoLink"><ahref="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::<spanclass="RenoLink"><ahref="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::<spanclass="RenoLink"><ahref="exception_ptr.html">exception_ptr</a></span>, but this requires that Boost Serialization throws exceptions using boost::<spanclass="RenoLink"><ahref="enable_current_exception.html">enable_current_exception</a></span>. If Boost Serialization calls boost::<spanclass="RenoLink"><ahref="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>Should I call boost::throw_exception or BOOST_THROW_EXCEPTION?</h3>
<p>It is preferable to throw exceptions using the <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> macro. This has the benefit of recording 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::<spanclass="RenoLink"><ahref="diagnostic_information.html">diagnostic_information</a></span> to compose a more useful, if not user-friendly message.</p>
<p>Typical use of boost::<spanclass="RenoLink"><ahref="diagnostic_information.html">diagnostic_information</a></span> is:</p>
<p>This is a possible message it may display, the first line is only possible if <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> is used:</p>
<pre>example_io.cpp(83): Throw in function void parse_file(const char *)
Dynamic exception type: class file_open_error
std::exception::what: example_io error
[struct tag_errno_code *] = 2, OS says "No such file or directory"
