Exception specifications on functions useless?
sbergman at redhat.com
Wed Mar 21 08:12:35 PDT 2012
On 03/21/2012 03:33 PM, Caolán McNamara wrote:
> On Wed, 2012-03-21 at 10:04 +0100, Stephan Bergmann wrote:
>> it would IMO be nice to nevertheless have information about functions'
>> exception behaviour around, in a form suitable for mechanical
>> verification. (For example by disabling GCC's -fno-enforce-eh-specs
>> for --enable-dbgutil builds.) But maybe that's only a hopeless pipe
>> dream of mine, anyway...
> Aren't we already doomed in the sense that if we take any signature
> virtual sal_Bool SAL_CALL foo(void) throw( uno::RuntimeException )
> then if that foo is implemented using various bits of boost magic or
> stl, and there's surely thousands that are, then they can throw loads of
> stuff, under various edge-conditions, which are unrelated to
> uno::RuntimeException unless foo does a pile of catching and converting
> std::exceptions into uno::RuntimeException ?
Yes, sure. It is a design error of the UNO C++ language binding that
all those functions do not additionally contain certain std exceptions
(bad_alloc, runtime_error, ios_base::failure, probably) in their
exceptions specifications. (And one can argue that it is a design error
of C++ to not offer a distinction between checked and unchecked
exceptions, a la Java.) Witness the handful of places in the code
(mostly written by myself, I guess) that *do* translate std::bad_alloc
into a UNO RuntimeException -- an arguably misguided approach I quickly
gave up on again. ;)
But that's a good argument that simply "disabling GCC's
-fno-enforce-eh-specs for --enable-dbgutil builds" wouldn't quite cut it.
More information about the LibreOffice