documentation update

[SVN r52280]

doc/current_exception.html

@@ -46,6 +46,7 @@ boost
 </a><a href="copy_exception.html">copy_exception<br/>
 </a><a href="enable_current_exception.html">enable_current_exception<br/>
 </a><a href="exception_ptr.html">exception_ptr<br/>
+</a><a href="frequently_asked_questions.html">Frequently Asked Questions<br/>
 </a><a href="unknown_exception.html">unknown_exception<br/>
 </a></div>
 </div>

doc/frequently_asked_questions.html

@@ -21,16 +21,9 @@
 <!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
 <div class="RenoIncludeDIV"><div class="RenoAutoDIV"><h3>Frequently Asked Questions</h3>
 </div>
-<h3>Why use operator&lt;&lt; overload for adding info to exceptions?</h3>
+<h3>Why doesn't boost::exception derive from std::exception?</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>
+<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>
-<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>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>
-<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 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 )
@@ -44,23 +37,12 @@ throw e;</pre>
     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>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>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>Why is boost::exception integrated in boost::throw_exception?</h3>
+<h3>Should I use boost::throw_exception or BOOST_THROW_EXCEPTION or just throw?</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 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 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>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>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>Should I call boost::throw_exception or BOOST_THROW_EXCEPTION?</h3>
-<p>It is preferable to throw exceptions using the <span class="RenoLink"><a href="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::<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 )
     {
@@ -78,6 +60,25 @@ std::exception::what: example_io error
 [struct tag_file_name *] = tmp1.xml
 [struct tag_function *] = fopen
 [struct tag_open_mode *] = 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>
 </div><div class="RenoAutoDIV"><div class="RenoHR"><hr/></div>
 <h3>See Also:</h3>
 <div class="RenoPageList"><a href="boost-exception.html">Boost Exception<br/>