Exception specifications on functions useless?

[Stephan Bergmann]

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
> like..
>
> 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.

Stephan