[res.on.exception.handling]

# 16 Library introduction [[library]](./#library)

## 16.4 Library-wide requirements [[requirements]](requirements#res.on.exception.handling)

### 16.4.6 Conforming implementations [[conforming]](conforming#res.on.exception.handling)

#### 16.4.6.14 Restrictions on exception handling [res.on.exception.handling]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3900)

Any of the functions defined in the C++ standard librarycan report a failure by throwing an exception of a type
described in its *Throws*: paragraph,
or of a type derived from a type named in the *Throws*: paragraph
that would be caught by a [*handler*](except.pre#nt:handler "14.1 Preamble [except.pre]") ([[except.handle]](except.handle "14.4 Handling an exception")) for the base type[.](#1.sentence-1)

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3908)

Functions from the C standard library shall not throw exceptions[156](#footnote-156 "That is, the C standard 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[.](#2.sentence-1)[157](#footnote-157 "The functions qsort() and bsearch() ([alg.c.library]) meet this condition.")

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3926)

Destructor operations defined in the C++ standard library
shall not throw exceptions[.](#3.sentence-1)

Every destructor in the C++ standard library shall behave as if it had a
non-throwing exception specification ([[except.spec]](except.spec "14.5 Exception specifications"))[.](#3.sentence-2)

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3932)

Functions defined in the
C++ standard librarythat do not have a *Throws*: paragraph
but do have a potentially-throwing exception specification
may throw implementation-defined exceptions[.](#4.sentence-1)[158](#footnote-158 "In particular, they can report a failure to allocate storage by throwing an exception of type bad_­alloc, or a class derived from bad_­alloc ([bad.alloc]).")

Implementations should
report errors by throwing exceptions of or derived
from the standard
exception classes ([[bad.alloc]](bad.alloc "17.6.4.1 Class bad_­alloc"), [[support.exception]](support.exception "17.9 Exception handling"), [[std.exceptions]](std.exceptions "19.2 Exception classes"))[.](#4.sentence-2)

[5](#5)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3952)

An implementation may strengthen the
exception specification
for a non-virtual function
by adding a non-throwing exception specification[.](#5.sentence-1)

[156)](#footnote-156)[156)](#footnoteref-156)

That is, the C standard library functions can all be treated as if they
are marked noexcept[.](#footnote-156.sentence-1)

This allows implementations to make performance optimizations
based on the absence of exceptions at runtime[.](#footnote-156.sentence-2)

[157)](#footnote-157)[157)](#footnoteref-157)

The functionsqsort() andbsearch() ([[alg.c.library]](alg.c.library "26.13 C library algorithms")) meet this condition[.](#footnote-157.sentence-1)

[158)](#footnote-158)[158)](#footnoteref-158)

In particular, they
can report a failure to allocate storage by throwing an exception of type[bad_alloc](bad.alloc "17.6.4.1 Class bad_­alloc [bad.alloc]"),
or a class derived frombad_alloc ([[bad.alloc]](bad.alloc "17.6.4.1 Class bad_­alloc"))[.](#footnote-158.sentence-1)
