程序健壮性

写了一年多的代码，不生不熟。很多代码是仿照前辈写的。很多地方不知道为什么，就知道，这么写，程序不容易出错。突然，有一天有人问我，什么是代码的健壮性（程序的健壮性）。急急忙忙上网找资料，现在联系实际与大家分享一下，同时欢迎大家补充和指正。

什么叫程序的健壮性：面对变态测试没有bug就算健壮的程序。下面以最常见的查找员工为例。

查找条件有员工工号（字符串），人员姓名（汉字），手机号码（字符串），岗位，工作职责，固定电话。

六个查询条件拼接成一个对象QueryCondition传到后台。

后台有一个方法 search（QueryCondition q）

不健壮的程序就是search 不管q为什么直接调用相应方法到数据库中查询。这样可能就有一大堆的空指针异常和一些奇奇怪怪的错误。那么要怎么做呢，处理你能想到的所有异常情况。

1.没有判断对象是否为空。----空指针异常

什么条件都没有，是不是就意味着查询所有数据。这样数据量小还勉强可以，要是数据量百万级，这样，你要么请求超时，要么内存溢出。

处理：程序中首先对q进行判断是否为空。接着对q中所有属性进行判断。如果全部为空。要么不让查询，要么调用一个方法分页查询。

2.字符串长度没有限制。------测试故意找茬

遇到过一个测试在姓名字段输入5000+汉字。具体多少不记得了，结果：这个查询调用的是一个存储过程，参数定义是varchar2（10）. 不产生异常就怪了。请不要说这是测试变态，这就是程序健壮性。其实我们在前台输入的时候对长度进行限制或者后台判断有没有超过某些程序中限制长度，建议前台做，比较简单。

3.数字限制-----不符合实际情况的输入

岗位是一个数字1-6级，根据岗位去匹配相应基本工资，岗位为除数。理论上岗位不会有负数和0.所以很多时候就不加处理。于是，当你输入0的时候就产生了一个ArithmaticException。好吧，我什么都不说了，怪自己。

4.字符串与数字之间的转换。----大坑

如果你输入手机号码，正常情况应该是全部数字。假设数据库中该列类型就是number类型，为了提高查询速度，所以在查询前会将字符串转换为数字。这就给自己埋了一个大坑。如果用户输入013123568978，或者-4654654654这些都是无法转换的。有时候我们不加判断就直接转换，程序不抛异常就怪了。

贴一个不那么常见的异常

1.邮件发送----内存溢出

for（//获取收件人信息

 for（）//生成附件并发送

）

这是一个两重循环。生成附件方法生成的附件先放在内存中，邮件发送出去就回收。

刚刚开始发送几十封，附件10m以内一点问题没有。以为该功能已经实现。不过不得不说测试牛，造了一个好几g的附件。这下够服务器喝一壶的了，内存溢出了。修复吧，把附件大小限制为10m以内。以为雨过天晴。没想到，最多一次发送4000+封邮件。为了加快发邮件速度，我还自以为聪明的使用了多线程。这次又溢出。

这此事故让我对内存产生了敬畏，不要以为内存永远够用。这个怎么避免我还没有完美的解决方案。最后我是牺牲了性能

2.接口限制--调用次数，资源阻塞

这种异常是我遇到的比较坑爹的。不是自己写的代码原因，但是还是会导致我的程序挂了。

有一次做一个地图类应用，调用的是xx的免费接口。程序一切正常，有一天我在吃着泡面，运维告诉你，屌丝，你的应用挂了。我的第一反应是不可能，都用了这么久了。速度吃掉老坛酸菜，看日志，xxx接口访问限制。我去，神马情况，一直好好的，咔咔开始调试。搞了半天搞不出来，实在没辙了，咨询了一下xx技术支持。才知道对于请求量2000+的ip是会被封掉的。不吐槽，免费的就是坑爹的。不过这种异常只能遇到一次解决一次。没有规律可循

总结一下：程序健壮性就是你的程序在遇到异常的情况下还能运行或者给予用户友好的提示。所以写代码的时候尽量考虑周全。该做异常处理的就做异常处理，性能和正确性比起来一文不值。

巴拉巴拉扯了这么多，好像都没啥技术含量一点都不高大上。贴一段别人关于程序健壮性的博文。高手写的就是不一样

http://www.cnblogs.com/zhuispeed/archive/2010/07/08/1773893.html