设计类型时，首先要想好类型的各种使用情况。类型名称通常是一个名词，例如FileStream或者StringBuilder。然后，要为类型定义属性、方法、事件等。这些成员的定义方式就是类型的编程接口。这些成员代表类本身或者类型实例可以执行的动作。行动成员通常用动词表示，例如Read，Write，Flush，Append，Insert和Remove等。当行动成员不能完成任务时，就应抛出异常。
重要提示：异常时指成员没有完成它的名称宣称可以完成的行动。
看一看下面类定义：
class Account
{
public static void Transfer(Account from, Account to, Decimal amount)
{
from -= amount;
to += amount;
}
}
Transfer方法接受两个Acount对象和一个代表账号之间的转账金额的Decimal值，显然，Transfer方法的作用是从一个账户扣除钱，把钱添加到另一个账户中。Transfer方法可能因为多个失败原因。例如，from或to实参可能为null；from或to实参可能没有引用打开的账户：from账户可能没有足够的资金；to账户的资金可能过多，以至于增加资金时账户溢出；amount实参为0、负数或者小数点后面的数字超过两位。
Transfer方法在调用时，它的代码必须检查前面描述的种种可能。检测到其中任何一种可能都不能转账，应抛出一个异常来通知调用者它不能完成任务。实际上，Transfer方法的返回类型为void。这是由于Transfer方法没有什么有意义的值需要返回。这一点很容易想得通；如果方法正常返回，表明转账已经成功；如果失败，就抛出一个有意义的异常。
面向对象编程极大提高了开发人员的开发效率，因为可以写这样的代码：
Boolean f="Jeff".Substring(1, 1).ToUpper().EndsWith("E");
这一行代码将多个操作连接在一起。我很容易写这样的代码，其他人也很容易阅读和维护，因为它的意图很明显；获取一个字符串，获取一部分，全部大写那部分，然后检查哪个部分是否以“E”结尾。出发点不错，但有一个重要的前提：没有操作失败，中途不出错。但是，错误总是可能发生的，所以需要一种方式处理那些错误。实际上，许多面向对象的构造-构造器、获取和设置属性、添加和删除事件、调用操作符重载和调用转换操作符等-都没有办法返回错误代码。但是，这些狗仔必须报告错误。.NET Framework和所有编程语言童工的机制就是异常处理。
重要提示：许多开发人员都错误的以为异常和某件事情的发生频率有关，例如，一个设计文件Read方法的开发人员可能会这样想：“读取文件时，最终会抵达文件尾部，由于抵达文件尾总是会发生的，所以我设计这个Read方法返回一个特殊的值来报告抵达了文件尾；我不让它抛出异常。”问题在于，这是设计Read方法的开发人员的想法，而非调用Read方法的开发人员的想法。
设计Read方法的开发人员不可能知道这个方法的所有的调用情形。所以，开发人员不可能知道Read的调用者尝试越过文件尾进行读取的频率。实际上，由于大多数文件包含的都是结构化数据。所以一路读取设置越过文件尾的情况是很少发生的。