<h3>What is the cost of calling boost::throw_exception?</h3>
<p>The cost is that boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> is added as a base of the exception emitted by boost::<spanclass="RenoLink"><ahref="throw_exception.html">throw_exception</a></span> (unless the passed type already derives from boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span>.)</p>
<p>Calling boost::<spanclass="RenoLink"><ahref="throw_exception.html">throw_exception</a></span> does not cause dynamic memory allocations.</p>
<h3>What is the cost of BOOST_THROW_EXCEPTION?</h3>
<p>In addition to calling boost::<spanclass="RenoLink"><ahref="throw_exception.html">throw_exception</a></span>, <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> invokes __FILE__ and __LINE__ macros. The space required to store the information is already included in sizeof(boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span>).</p>
<p>Calling <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> does not cause dynamic memory allocations.</p>
<h3>Should I use boost::throw_exception or BOOST_THROW_EXCEPTION or just throw?</h3>
<p>The benefit of calling boost::<spanclass="RenoLink"><ahref="throw_exception.html">throw_exception</a></span> instead of using throw directly is that it ensures that the emitted exception derives from boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> and that it is compatible with boost::<spanclass="RenoLink"><ahref="current_exception.html">current_exception</a></span>.</p>
<p>The <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> macro also results in a call to boost::<spanclass="RenoLink"><ahref="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 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>
<pre>catch(...)
{
std::cerr <<
"Unexpected exception, diagnostic information follows:\n" <<
<p>This is a possible message it may display -- the information in the first line is only available if <spanclass="RenoLink"><ahref="BOOST_THROW_EXCEPTION.html">BOOST_THROW_EXCEPTION</a></span> was used to throw:</p>
<pre>example_io.cpp(70): Throw in function class boost::shared_ptr<struct _iobuf> __cdecl my_fopen(const char *,const char *)
Dynamic exception type: class boost::exception_detail::clone_impl<class fopen_error>
<p>In some development environments, the first line in that message can be clicked to show the location of the throw in the debugger, so it's easy to set a break point and run again to see the unexpected throw in the context of its call stack.</p>
<p>Despite that <spanclass="RenoLink"><ahref="using_virtual_inheritance_in_exception_types.html">virtual inheritance should be used in deriving from base exception types</a></span>, quite often exception types (including the ones defined in the standard library) don't derive from std::exception virtually.</p>
<p>If boost::<spanclass="RenoLink"><ahref="exception.html">exception</a></span> derives from std::exception, using the <spanclass="RenoLink"><ahref="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 &) statements.</p>
<p>Of course, boost::<spanclass="RenoLink"><ahref="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 probably also be derived virtually.)</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>
<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">operator<<</a></span> allows this to be done directly in a throw expression:</p>
<p>The intention here is to throw a file_open_error, however if <spanclass="RenoLink"><ahref="exception_operator_shl.html">operator<<</a></span> fails to copy the std::string contained in the file_name <spanclass="RenoLink"><ahref="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>Therefore, the language itself does not guarantee that an attempt to throw an exception is guaranteed to throw an object of the specified type; propagating a std::bad_alloc seems to be a possibility even outside of the scope of Boost Exception.</p>
