diff --git a/doc/boost-exception.html b/doc/boost-exception.html index cb3f045..69051e4 100644 --- a/doc/boost-exception.html +++ b/doc/boost-exception.html @@ -26,9 +26,9 @@
Boost Exception also supports N2179-style copying of exception objects, implemented non-intrusively and automatically by the boost::throw_exception function.
namespace boost { - std::string diagnostic_information( boost::exception const & x ); + std::string diagnostic_information( boost::exception const & ); }
This function iterates over all data objects stored in the boost::exception through operator<<. The returned string is constructed by converting each data object to string and then concatenating these strings together.
-When the error_info<Tag,T> template is instantiated, the system attempts overload resolution for an unqualified call to to_string(x), where x is of type T. If this is successful, the to_string overload is expected to return std::string and is used to convert objects of type T to string.
-Otherwise, the system attempts overload resolution for s << x, where s is a std::ostringstream and x is of type T. If this is successful, the operator<< overload is used to convert objects of type T to string.
-Otherwise the system is unable to convert objects of type T to string, and an unspecified stub string value is used without issuing a compile error.
+This function returns a string value that is automatically composed from the string representations of all error_info objects stored in a boost::exception through operator<<, along with other diagnostic information relevant to the exception.
+The string representation of each error_info object is deduced by a function call that is bound at the time the error_info<Tag,T> template is instantiated. The following overload resolutions are attempted in order:
+The first successfully bound function is used at the time diagnostic_information is called; if all 3 overload resolutions are unsuccessful, the system is unable to convert the error_info object to string, and an unspecified stub string value is used without issuing a compile error.
namespace boost { - std::string diagnostic_information( boost::exception const & x ); + std::string diagnostic_information( boost::exception const & ); }
This function iterates over all data objects stored in the boost::exception through operator<<. The returned string is constructed by converting each data object to string and then concatenating these strings together.
-When the error_info<Tag,T> template is instantiated, the system attempts overload resolution for an unqualified call to to_string(x), where x is of type T. If this is successful, the to_string overload is expected to return std::string and is used to convert objects of type T to string.
-Otherwise, the system attempts overload resolution for s << x, where s is a std::ostringstream and x is of type T. If this is successful, the operator<< overload is used to convert objects of type T to string.
-Otherwise the system is unable to convert objects of type T to string, and an unspecified stub string value is used without issuing a compile error.
+This function returns a string value that is automatically composed from the string representations of all error_info objects stored in a boost::exception through operator<<, along with other diagnostic information relevant to the exception.
+The string representation of each error_info object is deduced by a function call that is bound at the time the error_info<Tag,T> template is instantiated. The following overload resolutions are attempted in order:
+The first successfully bound function is used at the time diagnostic_information is called; if all 3 overload resolutions are unsuccessful, the system is unable to convert the error_info object to string, and an unspecified stub string value is used without issuing a compile error.
#include <boost/exception/info.hpp>
+error_info( value_type const & v );
+Stores a copy of v in the error_info object.
+Any exception emitted by v's copy constructor.
+#include <boost/exception/info.hpp>
+value_type const & value() const;
+Returns a const reference to the copy of the value passed to error_info's constructor stored in the error_info object.
+Nothing.
+#include <boost/exception/info.hpp>
+typedef T value_type;
+The expression error_info<Tag,T>::value_type evaluates to T.
+The get_error_info function template is instantiated with the typedef from (1), and is passed an exception object of a polymorphic type. If the exception object contains the requested value, the returned shared_ptr will point to it; otherwise an empty shared_ptr is returned.
Sometimes the throw site does not have all the information that is needed at the catch site to make sense of what went wrong. Here is an example:
-#include <stdio.h> -#include <string> - -class -file_read_error - { - public: - - explicit - file_read_error( std::string const & fn ): - fn_(fn) - { - }; - - std::string const & - file_name() const - { - return fn_; - } - - private: - - std::string fn_; - }; - -void +Sometimes the throw site does not have all the information that is needed at the catch site to make sense of what went wrong. Let's say we have an exception type file_read_error, which takes a file name in its constructor. Consider the following function:
+void file_read( FILE * f, void * buffer, size_t size ) { if( size!=fread(buffer,1,size,f) ) - throw file_read_error("????"); + throw file_read_error(????); }-We have defined an exception class file_read_error which can store a file name, so that when we catch a file_read_error object, we know which file the failure is related to. However, the file_read function does not have the file name at the time of the throw; all it has is a FILE handle.
-One possible solution is to not use FILE handles directly. We could have our own class file which stores both a FILE handle and a file name, and pass that to file_read. However, this could be problematic if we communicate with 3rd party code that does not use our class file (probably because they have their own similar class.)
-A better solution is to make class file_read_error derive (possibly indirectly) from boost::exception, and free the file_read function from the burden of storing the file name in exceptions it throws:
+How can the file_read function pass a file name to the exception type constructor? All it has is a FILE handle.
+Using boost::exception allows us to free the file_read function from the burden of storing the file name in exceptions it throws:
#include <boost/exception.hpp> #include <stdio.h> #include <errno.h> @@ -140,7 +114,6 @@ parse_file( char const * file_name ) } }
The above function is (almost) exception-neutral -- if an exception is emitted by any function call within the try block, parse_file does not need to do any real work, but it intercepts any boost::exception object, stores the file name, and re-throws using a throw-expression with no operand (15.1.6). The rationale for catching any boost::exception object is that the file name is relevant to any failure that occurs in parse_file, even if the failure is unrelated to file I/O.
-As usual, the stored data can be retrieved using get_error_info.
The code snippet below demonstrates how boost::tuple can be used to bundle the name of the function that failed, together with the reported errno so that they can be added to exception objects more conveniently together: