在本文中，我们通过一个实例，来分析代码对过程中种种因素的影响。由于本文讨论的是面向对象代码，因此我们选择了面向对象的一个特性来进行分析。我们从案例的基本情况开始介绍，分析异常管理的基本思路，以及我们为什么需要引入对异常的管理。然后我们根据前文定义的分析框架来分析引入异常管理需要哪些方面的考虑，以及如何实施。
2. 案例的简单描述
需求分析阶段开始，软件开发就需要处理各种各样的异常序列，在用例设计中，除了正常的执行序列之外，还需要对各种各样的异常序列进行处理。编写代码也是这样，处理实现主要的功能之外，还需要对各种错误和异常进行处理。例如，编写一个处理Email的功能模块，处理能够正常的收发邮件之外，还需要能够处理服务端返回的错误，以及处理一些异常的情况，例如网络阻塞。
在传统的软件开发中，对错误的处理是基于返回码的，这种方式我们非常的熟悉，为了能够精确的定位错误，我们需要对返回码进行结构化的设计和分析，MFC框架就是此类的代表。我们举一个小例子：
private static char[] ReadSource(string filename)
{
FileInfo file = new FileInfo(filename);
if (errorCode == 2342) goto handler;
int length = (int)file.Length;
char[] source = new char[length];
if (errorCode == -734) goto handler;
TextReader reader = file.OpenText();
if (errorCode == 2664) goto handler;
reader.Read(source, 0, length);
if (errorCode == -5227) goto handler;
reader.Close();
Process(filename, source);
return source;
handler:
}
}
如果返回码简单的话，完全没有问题，但是如果返回值复杂的话，象上例这样，就显得非常的复杂和难懂了。在敏捷方法中，我们始终提倡自文档的代码写作风格，但是如果代码中充斥着各种各样的错误处理代码，那么会给代码造成很大的阅读难度。这是从代码风格的角度上说的，从设计的角度上看，错误码的本质是一个数值，是一个原生类型。而面向对象的威力就是在于能够准确的描述一个类型，将各种各样的错误情况都描述为数值不是面向对象提倡的风格。
因此，异常机制在过去的一段时间中，逐渐显现出其威力，慢慢的替换了陈旧的返回码机制。这里不打算对异常进行解释和举例，这种例子有很多。在Java语言中，异常的根是Throwable，在Throwable的层次中，异常大致可以分为三类：checked exception、runtime exception和error。根据JLS，使用的基本规则是在希望处理并恢复程序执行的情况下使用checked exception，对于error来说，往往意味着JVM内部处理非法的状态，程序已经不能够再执行了，代码不需要对这种情况进行处理。runtime exception一般用来指明程序错误，例如，用在指明前提条件违例的情况。
典型的异常的处理过程如下：
public sealed class PainLess{
public static int Main(string[] args)
{
try
{
string filename = args[0];
char[] source = ReadSource(filename);
Process(filename, source);
return 0;
}
catch (SecurityException caught) {
}
catch (IOException caught) {
} catch (OutOfMemoryException caught) {
} }
private static char[] ReadSource(string filename) {
FileInfo file = new FileInfo(filename);
int length = (int)file.Length;
char[] source = new char[length];
TextReader reader = file.OpenText();
reader.Read(source, 0, length);
reader.Close();
return source;
}
}
在将异常处理的代码集中一个地方之后，代码的流程就清楚了很多。
这样，看起来，在开发中规范异常机制，是有利于代码质量的改进的。这符合我们的第一个原则－有效原则。而从目前的技术来看，能够替代异常的机制尚未出现，而由于本案例假定环境的限制，我们无法选择其它更有效的提高代码质量的机制，所以我们认为这也符合第二个原则－更优原则。
那么，在下一章中我们将开始使用分析框架来分析问题。需要注意的一点是，我们并不按照分析框架定义的顺序来进行分析，因为顺序是无关紧要的。任何一个问题，可能有些要素容易分析，有些则比较难，我们完全可以先分析简单的，再考虑复杂的。而实施的时候，也基本上是按照这个思路来处理。
