On Thu, Mar 24, 2011 at 9:34 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Wed, 23 Mar 2011 14:29:20 -0700, Emil Dotchevski wrote:
On Wed, Mar 23, 2011 at 1:47 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
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,
It is not independent matter because that is exactly what BOOST_THROW_EXCEPTION guarantees, except when the library contains try..catch or rethrows using throw without arguments, which are rare cases. I agree that going the extra mile to workaround those additional cases is usually unreasonable.
I suppose that might be true, depending on your definition of "work properly." There's no such thing as "working properly without exceptions" if the library was coded for use with exceptions and you really need a recoverable response to, say, resource exhaustion.
Yes, if the program needs recoverable response, then BOOST_THROW_EXCEPTION is not going to work, and it is not at all desirable to require that libraries provide an alternative mechanism. However, this also means that BOOST_THROW_EXCEPTION will work just fine in other scenarios: 1) When the program can deterministically avoid using operations that throw. Example: using weak_ptr::lock instead of directly constructing a shared_ptr from weak_ptr (which may throw.) 2) When abort() is a reasonable response to failure. Example: in video games, it is typically OK to abort on file open or read failure, on failure to initialize the graphics system, etc.
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode