如果它们返回的是指针或迭代器，相同的结果还会发生，原因相同。reference、指针和迭代器统统都是所谓的handles（号码牌，用来取得某个对象），而返回一个“代表对象内部数据的handle”，随之而来的便是“降低对象封装性”的风险。同时，也可能造成“虽然调用const成员函数却造成对象状态被更改”。
通常我们认为，对象的“内部”就是指它的成员变量，其实不被公开使用的成员函数（protected或private）也是对象“内部”的一部分，所以也不该返它们的handles。否则，它们的访问级别就会提高到返回它们的成员函数的访问级别。
上述两个问题可以在它们的返回类型上加上const即可：
class Rectangle{
...
const Point& upperLeft()const {return pData->ulhc;}
const Point& lowerRight()const {return pData->lrhc;}
private:
std::tr1::shared_ptr
};
const 不在是个谎言。至于封装性，这里是蓄意放松封装，有限度的放松：只让渡读取权，涂写权是禁止的。
即使这样，返回“代表对象内部”的handles，有可能在其他场合导致dangling handles（空悬的号码牌）：
这种handle所指东西（的所属对象）不复存在。这种“不复存在的对象”最常见的来源就是函数返回值。
class GUIObject{...};
const Rectangle boundingBox(const GUIObject& obj);
现在，客户可能这么使用这个函数：
GUIObject *pgo;
...
const Point* pUpperLeft = &(boundingBox(*pgo).upperLeft());//取得一个指针指向外框左上点对boundingBox的调用获得一个新的、暂时的Rectangle对象，这个对象没有名称，权且称它为temp。随后upperLeft作用于temp对象身上，返回reference指向temp的一个内部成分。具体指向temp的那个Point对象。但是这个语句结束之后，boundingBox的返回值，也就是我们所说的temp，将被销毁，而那间接导致temp内的Points析构。最终导致pUpperLeft指向一个不再存在的对象；变成空悬、虚吊（dangling）！
只要handle被传出去了，不管这个handle是不是const，也不论返回handle的函数是不是const。这里的唯一关键是暴露在“handle比其所指对象更长寿”的风险下。
请记住：
避免返回handle（包括reference、指针、迭代器）指向对象内部。遵守这个条款可增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”的可能性降至最低。
条款29：为“异常安全”而努力是值得的
有个class用来表现夹带背景图案的GUI菜单单，这个class用于多线程环境：
class PrettyMenu{
public:
...
void changeBackground(std::istream& imgSrc);
...
private:
Mutex mutex;
Image* bgImage;
int imageChanges;
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
lock(&mutex);
delete bgImage;
++imageChanges;
bgImage = new Image(imgSrc);
unlock(&mutex);
}
从异常安全性的角度看，这个函数很糟。“异常安全”有两个条件：当异常被抛出时，带有异常安全性的函数会：
1.不泄露任何资源。上述代码没有做到这一点，因为一旦“new Image（imgSrc）”导致异常，对unlock就不会执行，于是互斥器就永远被把持住了。
2.不允许数据破坏。如果“new Image（imgSrc）”抛出异常，bgImage就指向一个已被删除的对象，imageChanges也已被累加，而其实并没有新的图像被成功安装起来。
解决资源泄漏的问题很容易，
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
Lock ml(&mutex);//来自条款14；
delete bgImage;
++imageChanges;
bgImage = new Image(imgSrc);
}
关于“资源管理类”如Lock，一个最棒的事情是，它们通常使函数更短。较少的代码就是较好的代码，因为出错的机会比较少。
异常安全函数（Exception-safe function）提供以下三个保证之一：
基本承诺：如果异常被抛出，程序内的任何事物仍然保持在有效状态下。没有任何对象或数据结构会因此而败坏，所有对象都处于一种内部前后一致的状态（例如所有的class约束条件都继续获得满足）。然而程序的现实状态恐怕不可预料。如上例changeBackground使得一旦有异常被抛出时，PrettyMenu对象可以继续拥有原背景图像，或是令它拥有某个缺省背景图像，但客户无法预期哪一种情况。如果想知道，它们恐怕必须调用某个成员函数以得知当时的背景图像是什么。强烈保证：如果异常被抛出， 程序状态不改变。如果函数成功，就是完全成功，否则，程序会回复到“调用函数之前”的状态。
不抛掷（nothrow）保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。作用于内置类型（如ints，指针等等）上的所有操作都提供nothrow保证。
异常安全码（Exception-safe code）必须提供上述三种保证之一。否则，它就不具备异常安全性。
一般而言，应该会想提供可实施的最强烈保证。nothrow函数很棒，但我们很难再c part of c++领域中完全没有调用任何一个可能抛出异常的函数。所以大部分函数而言，抉择往往落在基本保证和强烈保证之间对changeBackground而言，首先，从一个类型为Image*的内置指针改为一个“用于资源管理”的智能指针，第二，重新排列changeBackground内的语句次序，使得在更换图像之后再累加imageChanges。
class PrettyMenu{
...
std::tr1::shared_ptr
...
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
Lock ml(&mutex);
bgImage.reset(new Image(imgSrc));
++imageChanges;
}
不再需要手动delete旧图像，只有在reset在其参数（也就是“new Image（imgSrc）”的执行结果）被成功生成之后才会被调用。美中不足的是参数imgSrc。如果Image构造函数抛出异常，有可能输入流的读取记号（read marker）已被移走，而这样的搬移