Exception specifications (deprecated) aren't the same as checked exceptions, which I think was what some people might have in mind. In theory, they look like they solve a number of problems, but in practice they really create more than they solve. Even Java language designers have said that checked exceptions were a mistake.
The noexcept keyword was actually added to address some of the limitations.
I agree that these things get ugly very quickly. Another thing is that you aren't always catching all exceptions; for example, sometimes you are sure that something is in bounds, but the function is still declared as throws(out_of_range) or similar.
Is there a better way to do it, maybe a static analyzer or IDE warning about possible exceptions?
Instead of exceptions, I personally prefer using assertions to verify things like preconditions; in which case if an assertion fails the software should generally crash before getting into a worse state. Arguably, if the software shouldn't crash it's probably not an exception. Assertions can also give an analyzer a set of preconditions to check. For example, Clang's static analyzer parses assert statements [1]. I'm not sure it uses them to verify the preconditions, but regardless it's still a good way to express them.
Another way to express constraints are attributes, which static analyzers (and optimizers) also use. For example, GCC has a number of function attributes [2] to express invariants about code.
[1] http://clang-analyzer.llvm.org/scan-build.html#recommended_d...
[2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...
There was [0]. It is deprecated and generally discouraged, since it quickly becomes a maintenance nightmare (since you have to include unhandled exceptions for all functions called from that function, etc, all the way down).
[0] http://en.cppreference.com/w/cpp/language/except_spec