|
From: Dean M. B. <mik...@gm...> - 2011-03-31 01:58:39
|
On Thu, Mar 31, 2011 at 6:11 AM, Hochhaus, Andrew
<aho...@sa...> wrote:
> 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.
>
Cool!
If you can give me a pull request that would allow me to integrate
your changes in the library that would be *awesome*.
Thanks Andy!
--
Dean Michael Berris
http://about.me/deanberris
|