Support -fno_exceptions -DBOOST_NO_EXCEPTIONS within Beast

Beast currently does not support compilation with: -fno_exceptions even when the following are defined: -DBOOST_NO_EXCEPTIONS -DBOOST_EXCEPTION_DISABLE

read.ipp has multiple try/catch clauses that do not respect this configuration.

As per all boost libraries, one of the goals is to allow the user to define their own error handling mechanism, and enabling exceptions still degrades performance in real-time fault-tolerant applications. Suggestion is to identify all uses of try/catch in the library and make them obey configuration directives.

This will help

namespace detail {
template<class DynamicBuffer>
bool dynamic_prepare(
    boost::optional<typename DynamicBuffer::const_buffers_type>& buffer,
    std::size_t amount);
} // detail

Note that according to https://www.boost.org/doc/libs/develop/libs/beast/doc/html/beast/concepts/DynamicBuffer.html

DynamicBuffers are required to throw length_error if length_error if size() + n exceeds max_size(), so Beast could just check this condition before calling prepare, thus avoiding the need for the try catch block.

We still need the try/catch block because we want to convert length_error into an error_code. But this try/catch can be moved into a utility function (e.g. dynamic_prepare above) and then conditionally compiled based on BOOST_NO_EXCEPTIONS and BOOST_EXCEPTIONS_DISABLE. In addition, we can perform the length check you described, and return false if the check fails.

The combination of these ideas is very good and will move me forward in development right now. Thank you for your help and great work in this library. One question: will this change make it to the next official boost release? In my org environment, I can't include custom library code for release-grade build binaries very easily due to existing dev ops policies.

The next release is very soon, and this change might not be accepted by the release managers. However, I will ask - thanks!

Working on this now

@djarek how do we handle this: https://github.com/boostorg/beast/blob/ec1c8ada7a22b274cf6e58c019c2bbe6965f6232/include/boost/beast/http/string_body.hpp#L100

BOOST_TRY
{
  // ...
}
BOOST_CATCH(std::exception const&)
{
  // ...
} BOOST_CATCH_END

Catching all exceptions may be a bit too overzealous here, I think the only one that should be handled is std::bad_alloc.

Hi, I wanted to check in on the status of this. Can beast (specifically the websockets) be used with -fno-exceptions today? Sorry if this is in documentation somewhere, I couldn't find it. Thanks!

Not supported at present, but thanks for commenting on this issue. It's from before my time but I'll resurrect it.

I don't see this ever happening in Beast

Vinnie, does that mean the issue is rejected?

Does asio work without exceptions?

This issue is still marked as open despite #2611 being merged with the description saying it closes this issue. Is this still considered open?

This issue is still marked as open despite #2611 being merged with the description saying it closes this issue. Is this still considered open?

I believe the issue has been resolved, and we can now use Beast with -fno-exceptions. Are you experiencing any issues?

I have not yet used the library, I'm looking at a possible replacement to what I'm currently using and -fno-exceptions is a requirement so I wanted to confirm that this issue is resolved despite being still listed as open. Thanks for the quick response.

I believe so (and did some tests). Could you confirm, @klemens-morgenstern?

I think so.