关于异常的一点点小结
2014-04-17 00:23
225 查看
若本人对您有微微的帮助,将是我莫大的荣幸!
注意:为申明的本文讨论范围默认为java
初学者看看吧:
Throwable 是异常世界的超类,注意,此处“异常”指的是不正确的程序的,而非Exception,下面介绍它的子类
Error:错误,程序本身无法处理,如内存溢出,线程死亡,只能交给JVM去处理
Exception:异常,可以通过一定的方法来让程序继续正确执行,是可处理的,它包括:CheckedException 和 UncheckedException
关于 Java 中引入的 Checked Exceptions,目前存在着很多反对意见。正方的观点是引入 Checked Exceptions,可以增加程度的鲁棒性。反方的观点是 Checked Exceptions 很少被开发人员正确使用过,并且降低了程序开发的生产率和代码的执行效率。
正方代表 James Gosling
http://www.artima.com/intv/solid.html
反方代表 Anders Hejlsberg
http://www.artima.com/intv/csdes.html
中文版:http://www.csdn.net/develop/article/22/22612.shtm
本人倾向于正方观点,毕竟他能引导我编写更加正确的程序
CheckedException:受检异常,发生在编译阶段,必须被try...catch或者throws掉,否则编译不通过
UncheckedException:非受检异常,发生在运行阶段,有很多的不确定性,多有程序逻辑造成
若程序中显示的声明了某个异常,则抛出异常时不会显示出处,若程序中没有显示的声明某个异常,当抛出异常时,系统会显示异常的出处
一:尽可能的减小try块!!!
二:保证所有资源都被正确释放。充分运用finally关键词。
三:catch语句应当尽量指定具体的异常类型,而不应该指定涵盖范围太广的Exception类。
不要一个Exception试图处理所有可能出现的异常。
四:既然捕获了异常,就要对它进行适当的处理。不要捕获异常之后又把它丢弃,不予理睬。 不要做一个不负责的人。
五:在异常处理模块中提供适量的错误原因信息,组织错误信息使其易于理解和阅读。
六、不要在finally块中处理返回值。
七、不要在构造函数中抛出异常。
异常使用指南(摘自:Think in java)
应该在下列情况下使用异常。
1、在恰当的级别处理问题(在知道该如何处理异常的情况下才捕获异常)。
2、解决问题并且重新调用产生异常的方法。
3、进行少许修补,然后绕过异常发生的地方继续执行。
4、用别的数据进行计算,以代替方法预计会返回的值。
5、把当前运行环境下能做的事情尽量做完。然后把相同(不同)的异常重新抛到更高层。
6、终止程序。
7、进行简化。
8、让类库和程序更加安全。(这既是在为调试做短期投资,也是在为程序的健壮做长期投资)
下面是,对于异常的激烈讨论:
http://www.cnblogs.com/mailingfeng/archive/2012/11/14/2769974.html
尊重原创:
原文参考:http://blog.csdn.net/chenssy/article/details/17651909
注意:为申明的本文讨论范围默认为java
初学者看看吧:
Throwable 是异常世界的超类,注意,此处“异常”指的是不正确的程序的,而非Exception,下面介绍它的子类
Error:错误,程序本身无法处理,如内存溢出,线程死亡,只能交给JVM去处理
Exception:异常,可以通过一定的方法来让程序继续正确执行,是可处理的,它包括:CheckedException 和 UncheckedException
关于 Java 中引入的 Checked Exceptions,目前存在着很多反对意见。正方的观点是引入 Checked Exceptions,可以增加程度的鲁棒性。反方的观点是 Checked Exceptions 很少被开发人员正确使用过,并且降低了程序开发的生产率和代码的执行效率。
正方代表 James Gosling
http://www.artima.com/intv/solid.html
反方代表 Anders Hejlsberg
http://www.artima.com/intv/csdes.html
中文版:http://www.csdn.net/develop/article/22/22612.shtm
本人倾向于正方观点,毕竟他能引导我编写更加正确的程序
CheckedException:受检异常,发生在编译阶段,必须被try...catch或者throws掉,否则编译不通过
UncheckedException:非受检异常,发生在运行阶段,有很多的不确定性,多有程序逻辑造成
若程序中显示的声明了某个异常,则抛出异常时不会显示出处,若程序中没有显示的声明某个异常,当抛出异常时,系统会显示异常的出处
一:尽可能的减小try块!!!
二:保证所有资源都被正确释放。充分运用finally关键词。
三:catch语句应当尽量指定具体的异常类型,而不应该指定涵盖范围太广的Exception类。
不要一个Exception试图处理所有可能出现的异常。
四:既然捕获了异常,就要对它进行适当的处理。不要捕获异常之后又把它丢弃,不予理睬。 不要做一个不负责的人。
五:在异常处理模块中提供适量的错误原因信息,组织错误信息使其易于理解和阅读。
六、不要在finally块中处理返回值。
七、不要在构造函数中抛出异常。
异常使用指南(摘自:Think in java)
应该在下列情况下使用异常。
1、在恰当的级别处理问题(在知道该如何处理异常的情况下才捕获异常)。
2、解决问题并且重新调用产生异常的方法。
3、进行少许修补,然后绕过异常发生的地方继续执行。
4、用别的数据进行计算,以代替方法预计会返回的值。
5、把当前运行环境下能做的事情尽量做完。然后把相同(不同)的异常重新抛到更高层。
6、终止程序。
7、进行简化。
8、让类库和程序更加安全。(这既是在为调试做短期投资,也是在为程序的健壮做长期投资)
下面是,对于异常的激烈讨论:
http://www.cnblogs.com/mailingfeng/archive/2012/11/14/2769974.html
尊重原创:
原文参考:http://blog.csdn.net/chenssy/article/details/17651909
相关文章推荐
- 关于构造函数析构函数和异常的一点点
- 关于ul li的一点点小结
- 关于spring声明式事务管理异常处理的测试和小结
- Java常见异常(Runtime Exception )小结&&关于RuntimeException异常
- 关于devexpress grid更新插入异常小结
- 关于spring声明式事务管理异常处理的测试和小结
- Mahout小结:关于评估推荐系统估计值与实际值的偏差出现异常:DataModel doesn't have preference values
- 关于生命周期函数dealloc的使用小结
- 关于指针和函数和字符数组的一些小结
- 关于bug分析与异常处理的一些思考
- 关于Response.redirect和Response.End出现线程中止异常的处理
- 关于Io 异常: The Network Adapter could not establish the connection
- [Struts2异常]关于发生Struts配置异常:Unable to find parent packages struts-default.xml的解决方案
- Java中关于异常的一些问题(二)
- #Exception#Cpp引入异常的原因、关于异常的吐槽以及何时使用异常
- 关于SQL派生表用法的几点小结
- 异常小结
- 关于异常的合理处理方式
- 关于VB的WINSOCKET控件使用小结
- 关于Java抛出异常与处理异常的思考