|
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
|