Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)

Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-03-24 16:05:18

> Message du 23/03/11 21:49
> De : "Gruenke, Matt"
> A : boost_at_[hidden]
> Copie à :
> Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
>
> I use exceptions, but I'm also sympathetic to those who can't use or don't want them. I'm skeptical that all libraries can or should be designed to work without exceptions.
>
> Would it be possible to simply specify which libraries support exception-free operation, in a fashion similar to how certain libraries are called out as header-only? There's a potentially further distinction between libraries which propagate exceptions to the caller and those which only require them internally.
>
> Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled, and there might be legitimate reasons for libraries not designed to operate without exceptions use throw.
>
> IMO, separating these issues & potentially litigating them on a case-by-case basis could make this more tractable.
>
>
> Matt

Hi,

I agree that boost libraries are required to work without exceptions or rtti enabled, but I'm sure that people working on the embedded domains would be grateful if they could use some parts of Boost also.

They use to use C++ without exceptions and without RTTI as this features are not deterministic. I think that it will be a good thing if we can label the libraries that pass on these configurations.

The big question stay the one Dave made: What do they do on the throw_exception function? I think that most of them just are happy by aborting and restart, but maybe some people more experienced in this domain could share their experiences.

Note also the Beman proposal to pass an error code as argument to mean don't throw, so people working on these environments can use this specific interface. Of course this new parameter add a burden on the author side. Thinking a little bit more on this, the current implementation of Boost.Chrono provides such interfaces replacing exceptions by error codes, but doesn't ensures that no-exceptions are used.

Best,
Vicente