网站中异常设计思考

网站应用和其他应用（比如框架设计）有些不同之处，以下是对网站系统中异常设计和处理的一些思考。

1 异常
2 结果码
3 问题

1 异常

首先是关于异常的选择，Java的异常分为检查型异常和运行时异常，关于这两种异常的优缺点已经有无数人的无数文章做过讨论。
检查型异常是一个好东西，最大的优点是把异常作为了方法约定不可分割的一部分，强制性的要求方法调用者思考如果有异常该怎么处理。
但是缺点也是很明显的，比如异常淹没，过多的异常转化，代码的维护性降低等等。

从系统的角度看，发生异常有3种情况。

1 client的请求条件不满足，比如client输入参数错误，或者业务条件不满足，无法完成本次业务。
2 编程错误，程序员的问题，导致有异常。因为世界上没有完美的程序员，所以也没有完美的程序，我们需要考虑编程错误的处理方式。
3 系统错误，请求是合法的，编程是正确的，但是我们是在现实世界中，总有一些超时啊，连接不可用的异常。

对于1，可以使用检查型异常或者运行时异常。在界面上提示用户为什么本次操作不成功，引导用户继续操作。
对于2，建议使用运行时异常，在界面上提示用户系统暂时不可用，网站监控系统应该可以及时的发现这种异常，程序员又有bug可以搞了。
对于3，可以在系统级别进行重试，或者用运行时异常，用户界面提示用户系统繁忙，稍后重试。

异常的性能稍微差一点。
可以使用结果码来改进性能。

2 结果码

其实结果码的历史很长，现在的编程语言中也处处可以看到它的踪影。
和异常一样，结果码可以设计成全站唯一，也可以设计成各个子系统有自己的体系，这时各个系统的调用需要做结果码转化。
和异常一样，结果码也可以划分。
1 请求条件不满足的结果码。
2 编程错误用结果码很难表达，因为不知道哪里的代码有问题。这是废话，要是知道有问题，早就把它解决了。但是也是有一些可以预防的，比如case中没有考虑的情况等等。
3 系统错误结果码，包含系统异常，编程错误。系统异常被转化成系统错误结果码。在调用其他系统时，被调用系统的编程错误异常也会抛上来，也是要转化成系统错误结果码。
4 请求成功。
5 重发请求，对于重发请求各个业务根据自己的需要进行处理。

3 问题

不论是使用异常还是结果码，都面临一个核心的问题，如果底层的接口增加了异常情况怎么办？
对异常体系来说，可以设计出好的异常体系屏蔽掉子类型的增加对系统的影响。但是，问题在于客户就没有了友好的提示信息。当然友好的提示信息可以在异常生成的时候就设置，但是这也有问题，各个系统对业务的要求是不一样的，底层系统无法在被调用的时候知道上层的业务条件。
结果码面临的问题一样，当底层增加一个结果码的时候，上层的调用方必须增加对应的处理。
这个问题的实质就是：[b]异常情况本身就是方法不可分割的一部分，改变了异常情况，就是改变了接口，所以所有调用方都会受到影响。[/b]

没有一个好的方法可以从编程层面解决这个问题。
以下只是一些措施。
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();
}