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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
