网站中异常设计思考
网站应用和其他应用（比如框架设计）有些不同之处，以下是对网站系统中异常设计和处理的一些思考。
1 异常
2 结果码
3 问题
1 异常
首先是关于异常的选择，Java的异常分为检查型异常和运行时异常，关于这两种异常的优缺点已经有无数人的无数文章做过讨论。
检查型异常是一个好东西，最大的优点是把异常作为了方法约定不可分割的一部分，强制性的要求方法调用者思考如果有异常该怎么处理。
但是缺点也是很明显的，比如异常淹没，过多的异常转化，代码的维护性降低等等。
从系统的角度看，发生异常有3种情况。
1 client的请求条件不满足，比如client输入参数错误，或者业务条件不满足，无法完成本次业务。
2 编程错误，程序员的问题，导致有异常。因为世界上没有完美的程序员，所以也没有完美的程序，我们需要考虑编程错误的处理方式。
3 系统错误，请求是合法的，编程是正确的，但是我们是在现实世界中，总有一些超时啊，连接不可用的异常。
对于1，可以使用检查型异常或者运行时异常。在界面上提示用户为什么本次操作不成功，引导用户继续操作。
对于2，建议使用运行时异常，在界面上提示用户系统暂时不可用，网站监控系统应该可以及时的发现这种异常，程序员又有bug可以搞了。
对于3，可以在系统级别进行重试，或者用运行时异常，用户界面提示用户系统繁忙，稍后重试。
异常的性能稍微差一点。
可以使用结果码来改进性能。
2 结果码
其实结果码的历史很长，现在的编程语言中也处处可以看到它的踪影。
和异常一样，结果码可以设计成全站唯一，也可以设计成各个子系统有自己的体系，这时各个系统的调用需要做结果码转化。
和异常一样，结果码也可以划分。
1 请求条件不满足的结果码。
2 编程错误用结果码很难表达，因为不知道哪里的代码有问题。这是废话，要是知道有问题，早就把它解决了。但是也是有一些可以预防的，比如case中没有考虑的情况等等。
3 系统错误结果码，包含系统异常，编程错误。系统异常被转化成系统错误结果码。在调用其他系统时，被调用系统的编程错误异常也会抛上来，也是要转化成系统错误结果码。
4 请求成功。
5 重发请求，对于重发请求各个业务根据自己的需要进行处理。
3 问题
不论是使用异常还是结果码，都面临一个核心的问题，如果底层的接口增加了异常情况怎么办？
对异常体系来说，可以设计出好的异常体系屏蔽掉子类型的增加对系统的影响。但是，问题在于客户就没有了友好的提示信息。当然友好的提示信息可以在异常生成的时候就设置，但是这也有问题，各个系统对业务的要求是不一样的，底层系统无法在被调用的时候知道上层的业务条件。
结果码面临的问题一样，当底层增加一个结果码的时候，上层的调用方必须增加对应的处理。
这个问题的实质就是：异常情况本身就是方法不可分割的一部分，改变了异常情况，就是改变了接口，所以所有调用方都会受到影响。
没有一个好的方法可以从编程层面解决这个问题。
以下只是一些措施。
1 重视增加异常情况的重要性，这个相当于接口变更，一定要慎重，并且通知系统的调用方。激进的做法是改动这个方法的签名，这样所有的系统都会自动知道该接口已经变更。
2 接口返回的结果码一定是调用方可以理解的，避免返回一大堆调用方不关心的结果码，这个在接口设计中如果接口设计的太粗，会有这个问题。调用方应该处理每一种结果码。当遗漏一些结果码的时候，可以很快的通过编程异常发现。
3 对结果分类，确保不会遗漏大的分类。
如：
if(result.ok()){}else if(result.systemerror()){}else if(result.programmingError()){}else if(result.userError()){}else if(result.isRepeat()){}else{throw new ProgrammingException();} 2 楼 zhang_xzhi_xjtu 2010-08-15 duooluu 写道zhang_xzhi_xjtu 写道3 对结果分类，确保不会遗漏大的分类。如：
if(result.ok()){
}else if(result.systemerror()){
}else if(result.programmingError()){
}else if(result.userError()){
}else if(result.isRepeat()){
}else{
throw new ProgrammingException();
}
统一异常处理机制，流行的web框架都是有的
例如struts2的global-exception-mappings
springmvc的HandlerExceptionResolver
.......
规定好什么情况抛什么异常就好了
恩 这个是对结果的进一步细分，如果都采用配置，可能导致 1异常过多，配置过于麻烦。2 异常体系是扁平的，但是拿不到用户友好的信息。问题的核心还是如果增加了异常怎么办，这个问题框架并没有解决。 3 楼 hjg1988 2010-08-16 zhang_xzhi_xjtu 写道
...
3 问题
不论是使用异常还是结果码，都面临一个核心的问题，如果底层的接口增加了异常情况怎么办？
对异常体系来说，可以设计出好的异常体系屏蔽掉子类型的增加对系统的影响。但是，问题在于客户就没有了友好的提示信息。当然友好的提示信息可以在异常生成的时候就设置，但是这也有问题，各个系统对业务的要求是不一样的，底层系统无法在被调用的时候知道上层的业务条件。
结果码面临的问题一样，当底层增加一个结果码的时候，上层的调用方必须增加对应的处理。
这个问题的实质就是：异常情况本身就是方法不可分割的一部分，改变了异常情况，就是改变了接口，所以所有调用方都会受到影响。
没有一个好的方法可以从编程层面解决这个问题。
以下只是一些措施。
...
2 接口返回的结果码一定是调用方可以理解的，避免返回一大堆调用方不关心的结果码，这个在接口设计中如果接口设计的太粗，会有这个问题。调用方应该处理每一种结果码。当遗漏一些结果码的时候，可以很快的通过编程异常发现。
...
同意楼主的观点。
异常应该被认为接口或方法本身的不可分割的一部分。
返回码的定义要保证“一定是调用方可以理解的”，这个也很同意。 4 楼 lovemylover 2010-08-17 其实我一直觉得异常处理是系统中很重要但也很容易忽视的一部分，从某种意义上说，从一个系统的异常处理部分大致能够看出开发团队的水平、层次或者素养。在系统详细设计过程中，就应该考虑到异常体系的设计，比如异常的分类、处理异常的分层—AO层？业务层？展现层？）、接口功能中所可能发生的异常、异常发生后的处理（执行另一段代码？向上层抛出异常并最终以错误提示展现给用户？记入系统日志以方便进行错误追踪？）等等。这整个是一个很庞大的工程，而且在编码实现当中往往很枯燥繁杂，就算将这部分内容纳入编码规范，也会存在开发人员偷懒省工的可能，这个时候就考验团队的执行力以及QA的测试力度了。 5 楼 抛出异常的爱 2010-08-17 楼主淘宝架构师? 6 楼 zhang_xzhi_xjtu 2010-08-17 抛出异常的爱 写道楼主淘宝架构师?
老抛好敏锐
可惜不是
7 楼 wulinshishen 2010-08-17 呵呵，学习了 8 楼 mercyblitz 2010-08-18 Java中的Exception本来就很科学，可惜很多人不知道"珍惜"。大多数应用程序处理异常仅仅作为一种逻辑判断，殊不知异常既有层次，又可以归类。
可以学习一下数据库和操作系统，内建的 Error Code系统快速定位，并且友好的提示，并且引导客户处理异常。
无法避免的是，在一些接口中，异常类型不能细化的问题，那么不过多态性和Error code可以来帮助获取提示信息。同样，分类的异常也可以很好的解决，可以看一下HTTP协议的Response状态号。 9 楼 zhang_xzhi_xjtu 2010-08-18 mercyblitz 写道Java中的Exception本来就很科学，可惜很多人不知道"珍惜"。大多数应用程序处理异常仅仅作为一种逻辑判断，殊不知异常既有层次，又可以归类。
可以学习一下数据库和操作系统，内建的 Error Code系统快速定位，并且友好的提示，并且引导客户处理异常。
无法避免的是，在一些接口中，异常类型不能细化的问题，那么不过多态性和Error code可以来帮助获取提示信息。同样，分类的异常也可以很好的解决，可以看一下HTTP协议的Response状态号。
恩，我现在也觉得内建的Error Code是一个好东西了。
特别在系统到了一定的复杂性之后。 10 楼 抛出异常的爱 2010-08-18 zhang_xzhi_xjtu 写道抛出异常的爱 写道楼主淘宝架构师?
老抛好敏锐
可惜不是
结果码
这种上个世纪的设计方式
使用起来令人有寻死的想法.
PS:现在流行的方式是
抛出一个runtimeexception
用aop或struts.xml
使用全局异常来处理.
把异常看作一个可以跨越方法边界的goto来使用.设计异常的人飘过.参考我的名子 11 楼 zhang_xzhi_xjtu 2010-08-18 抛出异常的爱 写道zhang_xzhi_xjtu 写道抛出异常的爱 写道楼主淘宝架构师?
老抛好敏锐
可惜不是
结果码
这种上个世纪的设计方式
使用起来令人有寻死的想法.
PS:现在流行的方式是
抛出一个runtimeexception
用aop或struts.xml
使用全局异常来处理.
把异常看作一个可以跨越方法边界的goto来使用.设计异常的人飘过.参考我的名子
这个在本质上是没有什么区别的，用结果码，一样可以放在runtimeException里面。
如果只考虑用异常类型来区分异常的话，一样没有可能有办法得到各种异常的特定用户提示信息。
这里的焦点是如果得到特定用户提示信息，并且在底层异常有变化的时候，可以很好的对其应变。 12 楼 抛出异常的爱 2010-08-18 zhang_xzhi_xjtu 写道抛出异常的爱 写道zhang_xzhi_xjtu 写道抛出异常的爱 写道楼主淘宝架构师?
老抛好敏锐
可惜不是
结果码
这种上个世纪的设计方式
使用起来令人有寻死的想法.
PS:现在流行的方式是
抛出一个runtimeexception
用aop或struts.xml
使用全局异常来处理.
把异常看作一个可以跨越方法边界的goto来使用.设计异常的人飘过.参考我的名子
这个在本质上是没有什么区别的，用结果码，一样可以放在runtimeException里面。
如果只考虑用异常类型来区分异常的话，一样没有可能有办法得到各种异常的特定用户提示信息。
这里的焦点是如果得到特定用户提示信息，并且在底层异常有变化的时候，可以很好的对其应变。
特定信息......你用异常作常用判断么?
那是鲁棒性差的表现. 13 楼 downpour 2010-08-18 使用异常参与业务逻辑很多年前就开始被讨论。Robbin的观点是将异常参与到逻辑中去，作为一个异常事件流。起初我对这种做法是将信将疑的，不过通过几年的摸索，发现这才是一个最佳实践。
异常码决不是上个世纪的东西。台湾人常用异常码，欧美的项目中很难看到。不过最近在接触IBM的产品的时候，又一次看到了异常码。我后来仔细想了一下，异常码的使用实际上是一个产品化流程过程中的一个经历阶段。异常码实际上定义的是一类异常而非一个异常，这种情况下，异常的组织结构被淡化。所有的异常都来自RuntimeException，用异常码来区分异常的发生。
异常码的另外一个好处在于异常码在大型产品中可以被定义为一部数据字典，这个在IBM的产品中非常常见。同时，异常码还可以用于处理国际化等。在大型商业应用和产品级别的应用上，我越来越看得见异常码的光明前景。 14 楼 抛出异常的爱 2010-08-18 downpour 写道使用异常参与业务逻辑很多年前就开始被讨论。Robbin的观点是将异常参与到逻辑中去，作为一个异常事件流。起初我对这种做法是将信将疑的，不过通过几年的摸索，发现这才是一个最佳实践。
异常码决不是上个世纪的东西。台湾人常用异常码，欧美的项目中很难看到。不过最近在接触IBM的产品的时候，又一次看到了异常码。我后来仔细想了一下，异常码的使用实际上是一个产品化流程过程中的一个经历阶段。异常码实际上定义的是一类异常而非一个异常，这种情况下，异常的组织结构被淡化。所有的异常都来自RuntimeException，用异常码来区分异常的发生。
异常码的另外一个好处在于异常码在大型产品中可以被定义为一部数据字典，这个在IBM的产品中非常常见。同时，异常码还可以用于处理国际化等。在大型商业应用和产品级别的应用上，我越来越看得见异常码的光明前景。
问题是读不懂....
见过些银行项目
数据字典作成excl后有时会超过2W行上限.
而且现在ide还不支持对这种码的注释弹出.
无奈作出众多的异常类型....
放在不同的包下面
正在考虑作一个异常的工厂那样子方法上的注释就可以弹出来了. 15 楼 mercyblitz 2010-08-18 抛出异常的爱 写道zhang_xzhi_xjtu 写道抛出异常的爱 写道zhang_xzhi_xjtu 写道抛出异常的爱 写道楼主淘宝架构师?
老抛好敏锐
可惜不是
结果码
这种上个世纪的设计方式
使用起来令人有寻死的想法.
PS:现在流行的方式是
抛出一个runtimeexception
用aop或struts.xml
使用全局异常来处理.
把异常看作一个可以跨越方法边界的goto来使用.设计异常的人飘过.参考我的名子
这个在本质上是没有什么区别的，用结果码，一样可以放在runtimeException里面。
如果只考虑用异常类型来区分异常的话，一样没有可能有办法得到各种异常的特定用户提示信息。
这里的焦点是如果得到特定用户提示信息，并且在底层异常有变化的时候，可以很好的对其应变。
特定信息......你用异常作常用判断么?
那是鲁棒性差的表现.
其实在Try-Catch里面就是一种判断，不过可以利用多态性避免If else（实质还是逻辑判断）。
16 楼 mercyblitz 2010-08-18 抛出异常的爱 写道downpour 写道使用异常参与业务逻辑很多年前就开始被讨论。Robbin的观点是将异常参与到逻辑中去，作为一个异常事件流。起初我对这种做法是将信将疑的，不过通过几年的摸索，发现这才是一个最佳实践。
异常码决不是上个世纪的东西。台湾人常用异常码，欧美的项目中很难看到。不过最近在接触IBM的产品的时候，又一次看到了异常码。我后来仔细想了一下，异常码的使用实际上是一个产品化流程过程中的一个经历阶段。异常码实际上定义的是一类异常而非一个异常，这种情况下，异常的组织结构被淡化。所有的异常都来自RuntimeException，用异常码来区分异常的发生。
异常码的另外一个好处在于异常码在大型产品中可以被定义为一部数据字典，这个在IBM的产品中非常常见。同时，异常码还可以用于处理国际化等。在大型商业应用和产品级别的应用上，我越来越看得见异常码的光明前景。
问题是读不懂....
见过些银行项目
数据字典作成excl后有时会超过2W行上限.
而且现在ide还不支持对这种码的注释弹出.
无奈作出众多的异常类型....
放在不同的包下面
正在考虑作一个异常的工厂那样子方法上的注释就可以弹出来了.
上限问题好解决，也不一定要IDE支持，关键看规约就行了。
不过，异常太多了理解和维护起来岂不是更麻烦？
PS:这么投隐藏的人，是不是真的都明白？觉得简单就不要看，别手贱！ 17 楼 zhang_xzhi_xjtu 2010-08-18 异常的确是可以参与到业务中的，很多时候，一个FileNotFoundException和ZipException还是要区别对待的。异常参与业务，取决于我们怎么定义业务。 18 楼 mercyblitz 2010-08-18 zhang_xzhi_xjtu 写道异常的确是可以参与到业务中的，很多时候，一个FileNotFoundException和ZipException还是要区别对待的。异常参与业务，取决于我们怎么定义业务。
确实，你举的例子就是其中一种，这两类异常并没有层次关系，平行却有关联（同宗），都是继承于IOException。 19 楼 downpour 2010-08-18 抛出异常的爱 写道downpour 写道使用异常参与业务逻辑很多年前就开始被讨论。Robbin的观点是将异常参与到逻辑中去，作为一个异常事件流。起初我对这种做法是将信将疑的，不过通过几年的摸索，发现这才是一个最佳实践。
异常码决不是上个世纪的东西。台湾人常用异常码，欧美的项目中很难看到。不过最近在接触IBM的产品的时候，又一次看到了异常码。我后来仔细想了一下，异常码的使用实际上是一个产品化流程过程中的一个经历阶段。异常码实际上定义的是一类异常而非一个异常，这种情况下，异常的组织结构被淡化。所有的异常都来自RuntimeException，用异常码来区分异常的发生。
异常码的另外一个好处在于异常码在大型产品中可以被定义为一部数据字典，这个在IBM的产品中非常常见。同时，异常码还可以用于处理国际化等。在大型商业应用和产品级别的应用上，我越来越看得见异常码的光明前景。
问题是读不懂....
见过些银行项目
数据字典作成excl后有时会超过2W行上限.
而且现在ide还不支持对这种码的注释弹出.
无奈作出众多的异常类型....
放在不同的包下面
正在考虑作一个异常的工厂那样子方法上的注释就可以弹出来了.
不用读懂，只要有document可以reference就成。数据字典的大小不是问题，只要可查。
这东西的缺点我说了，是忽略异常的组织结构，其实2者是需要结合使用的。比如说，Spring的异常体系中，DataAccessException就可以作为一个比较大的根Exception来编写异常码，异常码可以规范到字符串的起始值或者代码数值的有效位数。在这种情况下，无论是数据字典的查阅还是程序员在写程序的时候，都不会遇到很大的问题。
其实归根结底是对业务的归类，我们讨论的前提条件是说BusinessException是我们需要处理的Checked Exception。所以作为构架师来说，设计合理的Exception层次结构并规范化，将是一个重要的任务。 20 楼 downpour 2010-08-18 zhang_xzhi_xjtu 写道异常的确是可以参与到业务中的，很多时候，一个FileNotFoundException和ZipException还是要区别对待的。异常参与业务，取决于我们怎么定义业务。
这两个Exception都不是RuntimeException，所以除非你需要让他参与到业务流程中来，将其转化为BusinessException，否则就应该抛出去或者处理掉。 21 楼 zhang_xzhi_xjtu 2010-08-18 downpour 写道zhang_xzhi_xjtu 写道异常的确是可以参与到业务中的，很多时候，一个FileNotFoundException和ZipException还是要区别对待的。异常参与业务，取决于我们怎么定义业务。
这两个Exception都不是RuntimeException，所以除非你需要让他参与到业务流程中来，将其转化为BusinessException，否则就应该抛出去或者处理掉。
举这个例子是为了说明即使同是一个大类的Exception，业务依然有可能需要看看到底是什么IOException，然后决定下一步怎么办，而不是通用的处理IOException完事。
处理异常未必只能设计异常体系，补充上结果码，或者全局errorcode也是一种选择。如果系统是静态不变的，那么所有的方案最后都是可以解决问题的，问题是需求会一直变，所以不论是异常还是结果码，都是不停的增加的，如何保证在这种动态性中的异常处理逻辑是对的。更美好的想法，如何保证用户尽可能得到的是一个用户友好提示，而不是一个系统不可用异常。