给JAVA设计开发新手一些建议和意见(2)

核心提示：【处理好你的异常】异常处理是java编程中非常重要的一个部分，建议在使用异常之前阅读或者，给JAVA设计开发新手一些建议和意见(2)，下面从书中摘出几条建议:*绝对不要忽略异常*千万不要隐藏异常****仅在不正常的情况下使用异常*对可恢复的情况使用可检查异常，对程序错误使用运行时异常(RunTimeException)

　　【处理好你的异常】
　　
　　异常处理是java编程中非常重要的一个部分。建议在使用异常之前阅读或者。
　　
　　下面从书中摘出几条建议:
　　
　　*绝对不要忽略异常
　　
　　*千万不要隐藏异常***
　　
　　*仅在不正常的情况下使用异常
　　
　　*对可恢复的情况使用可检查异常，对程序错误使用运行时异常(RunTimeException)
　　
　　*给方法引发的异常做文档
　　
　　*在具体信息里面包括失败捕捉信息
　　
　　*使用finally避免资源泄漏
　　
　　*。。。。
　　
　　在这里非凡提出的是，在开发中要非凡处理NULL的情况，否则经常引发NullPointException异常，在Java里这是一个最令人头疼的异常了。
　　
　　假如你的程序因为一个NULL值，而报了几十个NullPointException的话，不但得让人烦死，而且还非常难以找到错误所在。所以在Java中一定要注重这个问题。
　　
　　假如你的函数不答应Null值，那么可以截获它，抛出一个异常，或者给客户更友好的提示，难道不好吗?
　　
　　让我们来看一个例子:
　　
　　public String getName(User aUser)
　　
　　{
　　
　　//假如aUser为Null，会发生什么情况
　　
　　return aUser。getName();
　　
　　}
　　
　　很明显，假如参数为Null，就会抛出异常。应该改为:
　　
　　public String getName(User aUser)
　　
　　{
　　
　　if(null=aUser)
　　
　　{
　　
　　return "";
　　
　　}
　　
　　else
　　
　　{
　　
　　return aUser。getName();
　　
　　}
　　
　　}
　　
　　或者你要求参数不能为空，还可以抛出一个异常，强制使用者不能传入空值。
　　
　　还有经常被忽略的是RunTimeException和普通异常的区别，在Java中，这是一个非凡的异常类，程序中假如碰到这个异常，用户可以不截获它，而假如是其他的普通异常，就不许要截获它。我们的代码经常这么写:
　　
　　try
　　
　　{
　　
　　//your code here
　　
　　}
　　
　　catch(Exception e)
　　
　　{
　　
　　//do warn
　　
　　}
　　
　　这样写的话，就截获了所有异常，当然也包括了RunTimeException。 在很多情况下，这是不合适的处理方式，我们只应截获必要的异常，而应该忽略RuntimeException。
　　
　　关于RunTimeException，在SPRing中还有更好的利用方式，建议阅读Spring框架中在事务中对异常的处理代码，例如对Jdbc抛出的SqlException的转换。
　　
　　关于异常处理，我提出几点建议:
　　
　　*捕捉异常而且再次抛出时要包含原来的异常信息
　　
　　*不要忘了RunTimeException，除非必要，否则不要用catch(Exception e)的方式捕捉所有异常。
　　
　　*不要用异常做流程控制，异常的性能代价比较高昂。(对此，可能有人不同意。此处不具体讨论)
　　
　　*不要把异常处理都抛给别人，本函数有能力处理的就不要抛出。
　　
　　在此建议读者具体阅读或者。
　　
　　【过度依靠】
　　
　　在定位错误的时候，经常碰到浏览了七 八个文件还是没有找到什么地方执行了真正需要的函数，这个时候就非常郁闷。A调用了B，B调用了C，C调用了D。。。。。。让人找不到北
　　
　　面对这样的程序，存在的问题不仅仅是定位错误麻烦，而且假如需要维护这样的函数库/框架，恐怕你的有非常高的统御能力才行，否则打死我也不去维护。
　　
　　那么我们自己最好不要写这样的程序出来给人用。
　　
　　【滥用接口】
　　
　　现在流行"面对接口编程"，这本身本来是不错，但是滥用接口的现象却经常发生。
　　
　　"面向接口"，于是所有的类都有一个对应的接口，接口的函数声明和类一模一样，而且一个接口只有一个类来实现它。这样的面向接口有什么意义哪? (为了用Spring的事务的情况除外)
　　
　　根据"迪比特法则(Law of Demter)"，一个对象应当对其他对象有尽可能少的了解。一个接口内应该只定义对方所需要的方法，而不要把一些没用的方法声明放在接口里面。
　　
　　例如如下一个类:
　　
　　public class MyCounter
　　
　　{
　　
　　private int n1;
　　
　　private int n2;
　　
　　public MyCounter(int n1，int n2)
　　
　　{
　　
　　this。n1=n1;
　　
　　this。n2=n2;
　　
　　}
　　
　　public void setN1(int n1)
　　
　　{
　　
　　return this。n1 = n1;
　　
　　}
　　
　　public void setN2(int n2)
　　
　　{
　　
　　return this。n2 = n2;
　　
　　}
　　
　　public int getN1()
　　
　　{
　　
　　return n1;
　　
　　}
　　
　　public int getN2()
　　
　　{
　　
　　return n2;
　　
　　}
　　
　　public int getResult()
　　
　　{
　　
　　return n1 + n2;
　　
　　}
　　
　　}
　　
　　我们可以看到，这个类的主要目的是得到计算结果，所以正确的接口应该类似:
　　
　　public interface Counter
　　
　　{
　　
　　int getResult();
　　
　　}
　　
　　但是很多情况下，经常是这样的接口:
　　
　　public interface Counter
　　
　　{
　　
　　int getResult();
　　
　　int getN1();
　　
　　int getN2();
　　
　　void setN1(int n1);
　　
　　void setN2(int n2);
　　
　　}
　　
　　我们想一想，这样做有2个后果:
　　
　　1.除了getResult之外，其他的函数我们根本用不到，所以是多余的。
　　
　　2.假如我们要自己实现一个Counter，假如接口中仅仅定义了getResult，我们仅仅需要实现它就可以了。我们自己的类可能是多个数运算，有乘除加减等等各种运算，参数也有可能是一些数组。但是假如按照第二种方法声明接口的话，我们就必须实现后面的四个方法，假如这样的话，实现这样东西不仅没用，而且浪费时间。我们恐怕要大声骂娘了吧。
　　
　　所以，接口有好的作用，但是不要滥用。
　　
　　■ 假如你的接口永远只有一个类实现，那么可能就没有必要用接口。
　　
　　■ 你的接口只需要声明别人用到的函数即可。