From: Hochhaus, A. <aho...@sa...> - 2011-03-30 22:35:41
|
Hi Dean, On Mon, Mar 14, 2011 at 12:13 AM, Dean Michael Berris <mik...@gm...> wrote: >> On Sun, Mar 13, 2011 at 7:17 PM, Dean Michael Berris >> <mik...@gm...> wrote: >> The only other thing that I can think of is to "#ifndef >> BOOST_NO_EXCEPTIONS" comment out all "try {" clauses and "} catch { >> ... }" blocks in cpp-netlib. This should be a safe assumption as the >> user supplied throw_exception is never allowed to return (so no need >> to handle error conditions). >> >> An example of commenting out the "try ... catch" stuff can be seen in >> this patch to the thread library. >> >> https://svn.boost.org/trac/boost/attachment/ticket/2100/boost_thread_BOOST_NO_EXCEPTIONS_20110306.diff >> >> With those two changes, I believe that compilation should succeed with >> -fno-exceptions. >> > > Interesting. I think I need to think about that a little. There are a > few places where the exception mechanism is relied upon to convey > information to the user of the library -- like when an HTTP GET > actually fails, etc. I think it ought to be able to design interfaces > that take an lvalue reference to an optional error, or maybe just a > boost::system::error_code (maybe it's time that I implement a > boost::network::error_code that plays well with Boost.System much like > how Boost.Asio has the same). > > It might not be as simple as that too as with the asynchonous client > implementation relies on portable Boost.Exception types that are > encapsulated in Boost.Thread futures. I just learned about BOOST_{TRY,CATCH,CATCH_END,RETHREOW} from: third-party/boost/boost/detail/no_exceptions_support.hpp I think using these (combined with BOOST_THROW_EXCEPTION) is preferable to #ifndef BOOST_NO_EXCEPTIONS guarding that I previously suggested. Just thought I would mention them as they may be helpful. Thanks, -Andy |