【笨鸟先飞】Java重新学习日记9---异常处理

好吧，我就是想说说 try...catch....模块，

首先是最好用，也是最不好用的

Try{

内容1

}catch (Exception e) {
        e.printStackTrace();
}

   为什么说好用了，使用了这个try...catch....   内容1里面不管出现什么错误，都不会使虚拟机挂掉，从android程序来说，就是不会出现，程序错误，强制退出，这样的情况。

那么不好用呢，不好用是因为如果内容1里面真的有错误，那么从错误的地方开始，往后，内容1就白写了，会导致功能出不了，而不报错，你想要寻找出错误的地方就很困难了。

总之

Try{

内容1

}catch (Exception e) {
        e.printStackTrace();
}

就是异常与保护的最简单，最广泛用法，保护里面的内容1绝对不会因为各种原因导致程序死掉。

 

下面说说为什么要加保护。

情况1：用户或者系统不按照常理出牌。

在使用时，程序员期待用户会有一个正常的顺序，以及系统有个正常的反馈。比如，我要获取手机的地点，那么有没有可能获取的地点返回空值呢，因为系统不同意给与这个程序GPS权限。

用户呢，比如，我提供两个按钮供用户点击，按钮A显示时间，按钮B显示地点。用户无聊，就把这两个按钮狂点不止。导致在某个瞬间，显示器既要显示时间又要显示地点，结果报错了呢。

 

情况2：代码要求必须由异常说明

比如：多线程的sleep方法，必须抛出InterruptedException异常，可以throw也可以try catch。

这种在使用的时候后

 

 

 

Finally，是用在try catch之后的，我们应当知道，有些代码是成对出现的，比如course，创建了course就必须在尽量近的地方close掉。Finally就是用来进行close操作的，也就是资源回收，这个使用比较频繁，一般在使用数据库等地方，容易需要course和try...catch...

 

 

还有有常处理方法相关的是throw，比较常用的写法是throw new Exception（“自己写的说明”）

这个throw在这里的所用是，程序员自己判断，然后自己抛出异常。

 

异常的意义。在维护一个代码，寻找bug发生的原因的时候，如果bug是crash，即直接使程序挂掉，那么找到bug的位置就很容易。

反之，很难出现，偶尔的不知道什么情况下出现的错误，而且不报错，不引起手机任何不适，就是这个现象不再程序员的预想范围内，理论上不会出现的场景，他实际出现了，这种bug是很难的找打原因。

在集合里面，提到过我们会将对象批量处理，用上一章的模拟驾驶程序举例子，如果程序有个故障，在用户驾驶过程中，路边有个树的树顶出现了一只猴子。而这个猴子是不应该出现的。

这种时候，我们可以再添加路边物品的代码里面，在添加猴子的地方，加上throw new Exception。这样在运行到添加猴子的地方的时候，就会抛出异常了，我们就知道是哪里错误的添加了猴子。

 

这个时候可能会问：用Log也可以起到同样的效果，为什么要用throw new Exception。

Log只是打印一个语句，而throw new Exception除了语句之外，更重要的是，它会打印整个调用层次，就是是哪个顶层模块，调用的哪个模块A，然后模块B，然后一直调用到添加猴子的方法的。

所以，主动抛出异常的方法可以用来查找某个行为发生的时候的调用路径，非常好用。

 

 

 

回到try...catch...模块上，这个功能非常好用，Try...catch...是维护小概率事件的一种利器。大家也很喜欢用。

举个例子，我们首先想象一下，有一个程序A，它运行正常，久经沙场。然而有一次，他出现了一个故障，在某款特殊手机里安装程序B后，程序A就出现用一段时间会死掉重启的bug。寻找原因，发现是程序B往程序A发送一段程序A无法识别的特殊字符，于是程序A在读取这些字符的时候就报错了。

这里程序A有一个方法。

Public void getString(String input ){

 

String a = input;   //如果有报错应该是对a进行处理的代码，我们假设是这一句。

 

}

 

这个地方呢，只有接受程序B发送来的特殊字符才会报错，正常情况均不会出现，比较程序A是一个久经沙场。于是程序员就这么写了。

Public void getString(String input ){

Try{

String a = input; }catch (Exception e) {
        e.printStackTrace();
}

}

它的实际意义很简单，正常接收的文字，我们就好好处理，如果接收到来自其他程序的恶意字符，我们就不处理了，也别报错，无需重启程序A。

这样一写，是不是节省了工作量，对实际应用

 

但是由于它太好用，所以往往导致滥用。

甚至今天还吃了try...catch...的亏，直接导致一个功能失效。

我今天处理的是一个空指针故障，我所开发维护的代码很大，涉及模块很多，以至于经常被系统影响，导致面对空指针，一般我用两种方法解决

1：  if（a  ！= null）{

   a.方法

}

2：try...catch...

 

这种方法本身百试不爽，因为a为空，本身意味着在这个地方，我不需要a做事情，因为没有a，那么跳过这个地方就好了。

 

今天习惯性的使用了try...catch... ，而这次为空的原因是创建a对象的时间晚了，这个时候其他模块需要用a这个功能，而我还没有创建a，所以出现了错误。

 

我这个血淋淋的案例告诉大家，try...catch...可以用但不能乱用，甚至网上许多高手建议，不要try...catch...

确实，从某种角度说，try...catch...保护的异常都是可以通过代码判断规避的。

Try...catch...本身的意义是，不用if来疯狂判断特殊情况，另一方面，一个良好的代码和一个优秀的程序员，应该能够正确识别代码运行时的各种会发生的情况。这种时候，就不建议try...catch...了。

 

提供一Try{

内容1

}catch (具体的Exception e) {
        e.printStackTrace();
}

一种折中的办法，也是我非常建议的一种方法。Exception凡是异常都保护了，而具体的Exception则保护特点类型的故障，这样可以使程序在出现超出程序员预期的异常的时候，出现报错，而为了保证程序的功能不缺少，故障的方便锁定，我们是欢迎这些非预期故障以报错的形式出现。