I don't think so. For one c++17 added a lot of noexcept to functions, so it depends to which standard one is compiling against. cppreference is pretty good at documenting all that stuff.
Most functions with narrow contracts that are not marked noexcept potentially throw exceptions. This is because throwing an exception is an option if a library preconditon is violated.
Some implementations use this rule to good effect, throwing exceptions from functions that are called incorrectly in order to avoid more serious problems.
This rule shouldnt typically change the way you write code because you should not expect your program to violate a library's preconditions or exhibit undefined behavior.
Functions from the C standard library shall not throw exceptions (Note: That is, the C library functions can all be treated as if they are marked noexcept. This allows implementations to make performance optimizations based on the absence of exceptions at runtime.),
except when such a function calls a program-supplied function that throws an exception. (Note: The functions qsort() and bsearch() meet this condition.)
and
Destructor operations defined in the C++ standard library shall not throw exceptions. Every destructor in the C++ standard library shall behave as if it had a non-throwing exception specification.
Amended my post to say "most functions" instead of "all functions", thanks for the correction.
Essentially the absence of a "throws:" clause in the standard doesn't imply "no exceptions are thrown".
Instead it means "no exceptions are thrown if preconditions are satisfied". All this is covered in the linked papers.
right, a thing to consider is many library functions work with user-defined types. So vector<T, Alloc>::push_back does not have a "Throws" clause, but it will throw if T::T or Alloc::allocate does.