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.
- Re: Inclusion in an official release of a new throw-l... Aaron W. LaFramboise
-
