Re: Inclusion in an official release of a new throw-like qualifier

["Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>]

Jason Merrill wrote:
> Sergio Giro wrote:
> > I perceived that many people think that the throw qualifiers, as
> > described by the standard, are not useful
>
> Yes.  But that's not a reason to add a slightly different non-standard 
> feature that would require people already using standard exception 
> specifications to rewrite everything.  That's just a non-starter.

This is also the feature I'd like to see: a static checker for the 
existing throw specification feature.

I've been an advocate for eh specs, and I believe they are usable in 
their present form.  For reasons pointed out elsewhere, Java-esque 
static checking really isn't going to work for C++.  The only way that 
Java even gets away with it is why letting the vast majority of 
exceptions--those are derived from Error--slip through.  That is, Java 
throw(something) is equivalent to C++ throw(something, Error), where 
Java's Error is probably close to C++'s std::runtime_error. 
(Unfortunately std::bad_alloc and similar don't derive from 
std::runtime_error or share a common parent.)

The main problem with eh specs in their present form, besides poor 
support on some non-GCC compilers, is the lack of tools available to 
audit the specs.  This is a challenge to implement, as it needs to use 
non-intrusive decorators and heuristics to allow the user to indicate 
cases where exceptions logically won't propagate, even though they 
'theoretically could.'  Complete static checking would end up being the 
equivalent of -Weffc++: completely useless.

But I do think the compiler is the right place to do this sort of 
checking, as it needs to have available to it all of the same sorts of 
analysis as a compiler.  Good luck, Sergio, if you want to work on this.