Exception specifications on functions useless?
sbergman at redhat.com
Wed Mar 21 02:04:23 PDT 2012
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...
More information about the LibreOffice