blob: 48f12bcfbfd5c6a935e268b882873b8d5286f656 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Exception Guarantee Specifics</title>
</head>
<body bgcolor = "white">
<h1>Exception Guarantee Specifics</h1>
The following represent exception guaratee specifics, subject to the <a href="component_requirements.html#exception_requirements">component exception-requirements</a>.
<ol>
<li> <a name="basic_guarantee">No</a> resources are leaked in the face of exceptions. In particular, this means:
<ol>
<li>By the time a container's destructor completes:
<ol>
<li>It has returned all memory it has allocated to the appropriate deallocation function.</li>
<li>The destructor has been called for all objects constructed by the container.</li>
</ol>
<li>Algorithms destroy all temporary objects and deallocate all temporary memory even if the algorithm does not complete due to an exception.</li>
<li>Algorithms which construct objects either complete successfully or destroy any objects they have constructed at the time of the exception.</li>
<li>Algorithms which destruct objects always succeed.</li>
<li>Containers continue to fulfill all of their requirements, even after an exception occurs during a mutating function. For example, they will never give an inaccurate report of its size, or fail to meet performance requirements because of some thrown exception.</li>
</ol>
</li>
<li> <a name="strong_guarantee">The</a> <i>strong guarantee</i>: If an operation on a container fails due to an exception, then, semantically, the operation is a no-op applied to the container.</li>
<li> <a name="cannot_throw_guarantee">The</a> operation cannot throw an exception.</li>
</ol>
(The phrasing of the above is based on <a href="references.html#abrahams97exception">[abrahams97exception]</a>.)
</body>
</html>
|
