规范应当是从简单到复杂的，我们首先制定的规范并不复杂，只是对如何使用异常机制的一些定义。要获得这些规范并不困难，大部分介绍异常的技术资料中都给出了很多的建议。理解并使用它们，仅此而已。
1、 对不正常的条件使用异常，尽可能准确的使用预定义的异常。这一目标来自于Effective Java中的条款39和条款42。其目的是为了能够正确的使用异常。使用系统提供的异常能够减少代码，提高代码的可读性（特别是新人不需要了解自定义的异常结构）。大多数情况下，系统提供的异常已经足够用了。
2、 尽可能多的收集异常发生时的上下文信息。异常之所以比返回码优秀的一个原因就是它能够将错误类型化，提供比错误代码多得多的信息。因此，我们实在没理由不使用这一功能。
3、 正确的使用异常转义，并保留原异常信息。异常转义的目的是为了让客户端能够得到易于理解的类型。我们想象一个用户登录的情境，假设用户数据保存在一个文件中，当文件中找不到用户名的相关记录的时候抛出一个RecordNotFoundException异常，系统截获了这个异常，并将其发布给用户，问题在于，用户会觉得非常的奇怪，为什么会是记录没有找到呢？因此，建立一个IllegalUserException异常会更适合于这种情况。
4、 针对不同的抽象层次定义不同的异常。正如我们在第三点中提到的，RecordNotFoundException异常并不适合于用户这个层次。但是，这个异常对于程序员调试代码就很有意义了。
5、 将异常发布到合适的地方。有计算机的地方就一定有输入和输出。如果把异常发生时的信息收集看作输入，那么异常的输出是什么呢？可能是错误的提示信息，可能是一个显示错误信息的网页，可能是日志中的记录，可能是一条短信，也可能是一封EMail。这些就是异常的输出形式。此外，异常的输出还需要正确的确定对象，对用户来说，异常只要有一个友好的提醒方式就够了，但对于管理者来说，异常需要记录下来，或是通过异步消息进行通知。
这就是规范，你也可以把它称为最佳实践、建议等名词。当然，它还可以更加的细化，但事情总有个过程，一开始把问题弄得过于复杂未必是一件好事，你说呢？
有了规范是一回事，能否把规范运用起来则取决于人员的技能。在有一部描述清末的电影中，有这样一个情节，留学归来的知识分子为了提高民众的知识水平，不惜花费巨资免费发放报纸，这一举措大受欢迎，可惜大部分的民众都不识字，他们要报纸的原因只是这东西烧火很方便。
所以其次要解决的问题就是，大部分的程序员没有足够的异常处理经方面的技能。如果程序员没有这方面的概念，你把一本异常管理最佳实践放在他的面前会有用吗？
学会使用异常并不困难，困难的是如何让程序员正确的使用异常。什么时候使用系统定义的异常。什么时候使用自定义的异常，自定义异常又该如何设计。这些都是程序员的技能问题。
基于这种思路，首先做的是培训，而培训的目标是让程序员理解异常的机制，让程序员能够把异常运用到工作中。培训不等于上课，因为我们的目标是能够影响程序员的行为，单靠上课是无法达成目标的，因此我们把几种方式综合使用。一般来说，程序员对未知的技术总是有兴趣的，并且会尝试着运用，然后就会慢慢失去兴趣。这种对新技术的兴趣是可以利用的，但是要在兴趣过去之前将行为稳定下来。所以我们首先做的是挑选合适的程序员，他们要么就是有使用异常的经验，要么就是热衷于研究新技术，这些人是比较容易说服的。这些人的作用并不是限于学习，他们的主要职责是将这项技术传播到整个团队中。管理的本质其实是透过人来做事，而不是自己做事，所以传播知识的职责应该是由一个团队来共同承担，绝对不是一个技术主管上窜下跳的。我见过很多过于忙碌的技术主管，他们都犯了这个错误。
当我们在讨论会议上取得了对使用异常机制的共识之后。开始使用第二种方式－训练。训练分为两个部分，前半部分是讲述异常的机理、如何使用。这时候还不讲异常的最佳实践，因为大家还没能够熟练的使用异常，讲述最佳实践的效果不好。后半部分是让原先挑选的程序员辅导其他程序员练习异常的使用。练习的时间大约维持了3天，我们观察到项目开发的速度并没有受到很大的影响，因为训练并没有占用很多的时间，辅导的时间也是分布到项目开发中，但是我们知道，如果要在项目引入异常，一开始速度是一定会下降的。在首次训练完毕之后，是第二次的训练，这次主要是介绍异常管理的最佳实践。有了一定的使用经验之后，团队顺利的接受了这部分的知识。团队已经开始拥有了这方面的技能了。
由于是团队协作，因此我们考虑问题必须在团队环境中考虑，这就象多线程，在多线程环境中考虑问题的方式和单线程是截然不同的，任何问题都有基本的解决思路，团队协作中主要的问题包括沟通、信息传递、协作、计划等问题。所以我们解决问题的思路也是先定义出问题和要达到的目标，然后再来考虑方法。
我们认为，异常在组织中的最大作用是它清晰的定义了类开发者和类调用者之间的契约关系。所以，我们希望类的开发者清楚的说明一个方法在什么条件下会出现什么样的异常，类调用者则需要保证他的调用对异常有明确、完整的处理。
这个时候，我们需要过程的帮助了。
为了实现组织一节中定义的目标，我们对过程进行修订：
1) 在设计类时，需要同时设计异常类，并编写异常类的说明文档，通过复审。
2) 在给出类和方法的说明时，需要给出异常的定义和触发的条件。
3) 在代码中使用异常，而不是返回值。
4) 对输入参数进行判定，使用参数不正确异常和空指针异常。
5) 测试所有异常。
6) 方法调用时，如果方法中有异常，必须使用try块进行异常处理。
7) 异常需要通过通用的框架发布。
1、2、5三点属于设计的内容，3、4、6、7四点属于编码的内容。
注意到了吗？这种过程的定义是非常具体的，准确的说这类似于作业流程。很多软件组织都没有做这方面的工作。抽象的制度是没有意义的，比如这么一条，严谨的做好软件测试。什么叫严谨？软件测试的基本原理就是你不可能测试所有的情况，那么，严谨到底是测试到什么地步，没人知道。而我们这里的定义则不一样，方法中抛出的异常都需要测试。非常的明确，如果你的代码中抛出了3个异常，那么你就需要至少三个测试方法来测试它们。
当然，其实这个过程制度还是不完整的，我们拿第4条来说，它就有几个问题：首没有指明两种异常的使用环境；没有规定异常如何收集上下文环境。但是，我们认为，制度性的规章不必要定义的如此复杂，你见过法律规定拿匕首杀人定什么罪，拿刀子杀人定什么罪吗？你可能会问，刚才你说制度要定义的细一些，现在又说不要定义的这么细，这不是自相矛盾吗。不，任何问题的解决方法都是在不同的因素间进行权衡，而我们是在制度的可操作性和抽象性之间权衡。这也是敏捷思维的一部分。团队中知识的传递决不是靠一纸规章就能够完成的。那么应该怎么做？两种方法，一个是靠口头讲述使用方法，另一个是通过我们原先指定的"辅导员们"。
但在这时候，新的问题又产生了。类设计者如何把异常告诉类使用者呢，他们如何做到第2条呢？，第7条中的通用的框架又该如何设计呢？这时候我们必须求助于工具。
我们先解决第一个问题。这个问题的根本在于，类设计者如何编写异常文档。在Java语言中，我们可以很容易的使用语言本身的功能和JavaDoc工具来解决这个问题。但是在其它的语言中，我们可能需要第三方的工具，甚至自己编写工具。
第二个问题在Java中同样有比较好的解决思路。Log4J是Apache组织下的一个优秀的处理日志的开放式框架。使用它能够很方便的将异常发布到各种途径中，例如Console、Windows日志、邮件、文本。无疑这正是我们需要的。至于其它的语言，那就只能靠各位看官发挥自己的能力了。
我不得不说这是最神秘，最难处理的一点。更糟糕的是，我发现很难把这个问题描述清楚。所幸的是，有一件事情让我印象深刻：
一次程序员A和程序员B为了一件事情争论。B编写了用户注册的后端控件，A负责调用。A的代码大致上是这样的：
{
doUserLogon();
} catch (LogonException le)
{
//异常处理代码
}
这样的代码看起来似乎没有什么问题，但是实际上却出错了，问题的现象是在测试重复用户的时候，没有任何现象发生。在debug的时候，B告诉A，其实对于重复用户的设计是通过返回值的，返回值非0表示有重复用户。所以正确的调用代码应该是这样的：
{
if doUserLogon()
{ … }
else
{ … };
} catch (LogonException le)
{
//异常处理代码
}
你认为是哪一位程序员犯错了呢？A有错吗？他的调用方式其实并没有错误，而且，他也并不知道B的设计思路。那么是B的错吗？B的异常处理思路也没有什么问题，他把异常用在非常的条件中，例如数据库连接失败。对于用户重复这样的分支，应该看作是一种正常的返回。那么是过程的问题了，至少B应该提供完整的类使用文档。话虽如此，但是一个软件组织的资源毕竟是有限的，Sun公司能够为他的Java API提供详尽的文档，你认为有多少公司可以做到呢？而且在团队内部仍然采用这种高成本的沟通方式，其实是不太好的。
我想来想去，这件事情应该属于个性的范畴。任何一个人都有自己的背景和性格。你永远无法指望大家能够写出一样的代码。作为类的编写者B，他无法知道A将会以什么样的方式来调用他的代码，与此对应的，类的使用者A也不清楚B编写的代码的细节，因为根据类的设计原则，类的实现细节不应该透露给外部。这中间出现错配也是正常的。
这个问题还是有办法解决的－为代码定义统一的风格，也就是固定一种编码风格。在技术实现上，我比较倾向于程序员A，因为第二种代码要比第一种代码复杂和难读。一个优秀的类设计人员应该在简化客户端调用上下功夫。在代码中包含了过多的路径导致类的测试和使用变得困难。当然，我在很多资料上也看到了很多不同的见解，但不管是哪一种见解，最佳的做法是在组织内统一做法。所以在我们的组织中，都只使用两种序列，要么正常返回，要么发生有类型异常。
但这是否解决了问题呢？这个问题可能是解决了，但还会有很多类似的问题。所幸的是，这个错误最终是被发现了，可能软件中还存在大量未被发现的错误，这些才是最可怕的。其实这个问题的根源在于，程序员之间的沟通不够。而要解决这个问题，我们认为，只能从文化上去想办法，提倡沟通，提倡协作。而我们的分析框架中并没有文化这一项。理由是，文化的主题超出了我们讨论的范畴。《创建软件工程文化》一书是一本讨论文化的优秀书籍，如果大家有兴趣，可以进一步的阅读。
所以，这里我们可以知道一个道理，软件工程、项目管理其实并没有什么非常难的地方，我们看很多书把很多问题都提到纯理论的高度，反而给读者造成了困扰。很多读者的来信中，问到一个同样的问题，我希望在我的团队中引入软件工程，有些人说从需求管理开始比较好，有些人说从配置管理开始比较好，到底应该从哪里开始呢？就拿这个例子来说，为什么我们对一个异常管理如此的关心呢？为什么不做需求管理，或是上CMM呢？那该多酷啊！问题就在这里，软件开发是为了给客户带来价值，就像UMLChina的名言，软件以用为本，而不是以酷来衡量的。异常管理的最终目的是为了提高软件质量，这是立竿见影的效果，能够给老板、给同事以信心。需求管理和CMM当然也可以达到这种效果，问题是，异常管理几乎不需要多少的成本，却能够达到直接的效果，这种好事，为什么不做？
事情到了这一步，程序员的行为已经开始慢慢规范了。注意，我们先激发大家的兴趣，再使用制度来规范行为。但是，这里还有一个问题，我们之前提到，使用新技术一定会在短期造成生产力的降低。好的，现在我们确实发现生产力降低了，因为程序员必须思考什么时候使用异常，如何使用，并编写文档和测试。所以我们在之前已经做了一件事，就是取得老板的支持，这一点至关重要。这也许也是属于文化的范畴吧。
好了，软件过程是需要不断的改进的，我们的案例讨论也体现了这一点，这个案例还可以讨论很多，但是处理的思路基本一致。找出可能存在的问题，思考相应的对策来规范行为，再发现问题，再规范行为。这样形成了一个不断循环不断进步的过程。