Exception specifications on functions useless?

[Stephan Bergmann]

On 03/20/2012 10:50 PM, Lubos Lunak wrote:
>   I've just found out that exception specification on functions in LO have been
> just pretty comments, for about 10 years.
[...]
>   I found out by compiling LO with Clang, running it and having it crash where
> gcc-compiler version had no problem. Stephan Bergmann and repo history
> revealed that in 2001 -fno-enforce-eh-specs was added to gcc's flags, turning
> off code generated that ensures these specifications are actually followed
> (and MSVC has reportedly never cared). Clang does not have the option. I've
> already actually fixed the problem (in
> vbahelper/inc/vbahelper/vbaccesshelper.hxx) and it appears the specifications
> somehow magically haven't rotten, as now LO runs fine for me (as far as I can
> say, I can't test everything).

IIRC, Sun Studio enforced std::unexpected semantics until the last day 
we actively used it, so effectively the code had only about a one-year 
chance to rot after all.

>   I'm not strongly biased either way, but what we have right now are really
> just pretty comments on functions. I think we should either say that we use
> the specifications, in which case -fno-enforce-sh-specs should not be used at
> least in debug builds, or we can say we follow the C++11/Boost/etc. trend and
> not use them, in which case we can have one macro for portable way of saying
> noexcept and have an EasyHack for removing the other specifications. BTW, it
> should be also noted that SAL_THROW() expands to nothing with gcc.

I'm undecided about the state of C++ exceptions.

On the one hand, the design of C++ exceptions has severe limitations:

* Exceptions are not properly integrated with the type system.  A 
function type definition cannot have an exception specification. 
Function templates cannot abstract over exception specifications.

* The old std::unexpected design easily pessimizes implementations of 
functions with exception specifications.  (The new noexcept design 
mitigates that, at the cost of weakening the static information 
available about a program, see below.)

Those limitations diminish the usefulness of exception specifications in 
practice, hence the trend to ban them.

On the other hand, writing robust programs requires robust foundations. 
  It is my firm belief that we need more statically derivable knowledge 
about programs, not less.  For client code to interact with a function, 
it is important to know as precise a specification of the function as 
possible.  What are its accepted inputs, how and with which values can 
it return, what are its side effects.  And the exceptions thrown by the 
function make no exception here.  If it shall be possible to 
programmatically react to exceptions thrown by a function, it is 
important to know what exceptions the function can throw and what the 
program state will be in such a case.  And it is advantageous for a 
language to be able to enforce and verify as much static knowledge as 
possible.  After all, "well-typed programs can't go wrong."  In that 
light, the fundamental Java exception design IMO makes a lot of sense, 
distinguishing between checked exceptions (that are supposed to be 
handled programmatically) and unchecked ones (that act more like 
asserts, or are intended to bring down the complete (sub-)system).

So if we follow the trend and ban old-style dynamic exception 
specifications from our C++ code base, 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...

Stephan