NullPointerException异常的原因及java异常??

所谓空指针异常,是因为用空(null)去调用属性或方法。null表示没有这个对象,既然没有这个对象,那么去调用他的属性和方法,就会报异常。<--主要有以下几种原因:1、使用了未初始化的变量

 所谓空指针异常,是因为用空(null)去调用属性或方法。   null表示没有这个对象,既然没有这个对象,那么去调用他的属性和方法,就会报异常。   <--主要有以下几种原因:   1、使用了未初始化的变量(虽然已经声明)   2、使用了未初始化的对象(虽然已经声明)   3、使用了关键字或已存在的类名作变量对象方法或类名。   当应用程序试图在需要对象的地方使用 null 时,抛出该异常。   <--这种情况包括:   调用 null对象的实例方法。   访问或修改null对象的字段。   将null作为一个数组,获得其长度。   将null作为一个数组,访问或修改其时间片。   将null作为Throwable值抛出。 (以上几点看明白,然后再查看你的代码,肯定能找出来)

 

空指针异常。

一般报java.lang.NullPointerException的原因有以下几种: 1.字符串变量未初始化; 2. 接口类型的对象没有用具体的类初始化,比如: 3. List lt; 会报错 4. List lt = new ArrayList(); 则不会报错了 5. 当一个对象的值为空时,你没有判断为空的情况。 你可以试着把下面的代码前加一行代码:

if(rb!=null);

String类型的对象可以做如下判断

if(rb!==null&&!"".equals(rb)) ……

当然还可以多做一个判断,是否不为空字符串

if(rb!==null&&!"".equals(rb.trim()))

 

JDK8发布以及多日了,今天,想体验一下,安装之后,试着导入原来的一个Project,结果报出两个红叉:
The type java.lang.CharSequence cannot be resolved. It is indirectly referenced from required .class files
The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files
很不理解,原来好好的一个项目怎么就报错了呢,网上搜了一下也没找到解决方法,无奈,只有退回原来的JDK7,
然后一切都恢复正常了,很是不解!
-----------------------------------------------解决方案
eclipse+tomcat7+jdk1.6
上面报错的方式我的解法方法是吧jre8换成6的就好了
选中项目-》右键-》build path ->找到add library -》选择JRE System Liberary》进入界面选择alternate jre ->在后面的installed jres..
里选择jdk1.6的目录上的jre -》ok 之后 清楚 构建下就好了

 --------------------------回忆一下java异常

异常机制概述

异常机制是指当程序出现错误后,程序如何处理。具体来说,异常机制提供了程序退出的安全通道。当出现错误后,程序执行的流程发生改变,程序的控制权转移到异常处理器。

异常处理的流程

当程序中抛出一个异常后,程序从程序中导致异常的代码处跳出,java虚拟机检测寻找和try关键字匹配的处理该异常的catch块,如果找到,将控制权交到catch块中的代码,然后继续往下执行程序,try块中发生异常的代码不会被重新执行。如果没有找到处理该异常的catch块,在所有的finally块代码被执行和当前线程的所属的ThreadGroup的uncaughtException方法被调用后,遇到异常的当前线程被中止。

异常的结构

异常的继承结构:Throwable为基类,Error和Exception继承Throwable,RuntimeException和IOException等继承Exception。Error和RuntimeException及其子类成为未检查异常(unchecked),其它异常成为已检查异常(checked)。 
NullPointerException异常的原因及java异常??

Error异常

Error表示程序在运行期间出现了十分严重、不可恢复的错误,在这种情况下应用程序只能中止运行,例如JAVA 虚拟机出现错误。Error是一种unchecked Exception,编译器不会检查Error是否被处理,在程序中不用捕获Error类型的异常。一般情况下,在程序中也不应该抛出Error类型的异常。

RuntimeException异常

Exception异常包括RuntimeException异常和其他非RuntimeException的异常。
RuntimeException 是一种Unchecked Exception,即表示编译器不会检查程序是否对RuntimeException作了处理,在程序中不必捕获RuntimException类型的异常,也不必在方法体声明抛出RuntimeException类。RuntimeException发生的时候,表示程序中出现了编程错误,所以应该找出错误修改程序,而不是去捕获RuntimeException。

Checked Exception异常

Checked Exception异常,这也是在编程中使用最多的Exception,所有继承自Exception并且不是RuntimeException的异常都是checked Exception,上图中的IOException和ClassNotFoundException。JAVA 语言规定必须对checked Exception作处理,编译器会对此作检查,要么在方法体中声明抛出checked Exception,要么使用catch语句捕获checked Exception进行处理,不然不能通过编译。

在声明方法时候抛出异常

语法:throws(略)
为什么要在声明方法抛出异常?
方法是否抛出异常与方法返回值的类型一样重要。假设方法抛出异常却没有声明该方法将抛出异常,那么客户程序员可以调用这个方法而且不用编写处理异常的代码。那么,一旦出现异常,那么这个异常就没有合适的异常控制器来解决。
为什么抛出的异常一定是已检查异常? 
RuntimeException与Error可以在任何代码中产生,它们不需要由程序员显示的抛出,一旦出现错误,那么相应的异常会被自动抛出。遇到Error,程序员一般是无能为力的;遇到RuntimeException,那么一定是程序存在逻辑错误,要对程序进行修改;只有已检查异常才是程序员所关心的,程序应该且仅应该抛出或处理已检查异常。而已检查异常是由程序员抛出的,这分为两种情况:客户程序员调用会抛出异常的库函数;客户程序员自己使用throw语句抛出异常。
注意:
覆盖父类某方法的子类方法不能抛出比父类方法更多的异常,所以,有时设计父类的方法时会声明抛出异常,但实际的实现方法的代码却并不抛出异常,这样做的目的就是为了方便子类方法覆盖父类方法时可以抛出异常。

在方法中如何抛出异常

语法:throw(略)
抛出什么异常?
对于一个异常对象,真正有用的信息是异常的对象类型,而异常对象本身毫无意义。比如一个异常对象的类型是ClassCastException,那么这个类名就是唯一有用的信息。所以,在选择抛出什么异常时,最关键的就是选择异常的类名能够明确说明异常情况的类。
异常对象通常有两种构造函数:一种是无参数的构造函数;另一种是带一个字符串的构造函数,这个字符串将作为这个异常对象除了类型名以外的额外说明。

为什么要创建自己的异常?

当Java内置的异常都不能明确的说明异常情况的时候,需要创建自己的异常。需要注意的是,唯一有用的就是类型名这个信息,所以不要在异常类的设计上花费精力。

throw和throws的区别

 

补充:throwChecked函数的另外一种写法如下所示:

注意:此时在main函数里面throwChecked就不用try异常了。

应该在声明方法抛出异常还是在方法中捕获异常?

处理原则:捕捉并处理哪些知道如何处理的异常,而传递哪些不知道如何处理的异常

使用finally块释放资源

finally关键字保证无论程序使用任何方式离开try块,finally中的语句都会被执行。在以下三种情况下会进入finally块:
(1) try块中的代码正常执行完毕。
(2) 在try块中抛出异常。
(3) 在try块中执行return、break、continue。
因此,当你需要一个地方来执行在任何情况下都必须执行的代码时,就可以将这些代码放入finally块中。当你的程序中使用了外界资源,如数据库连接,文件等,必须将释放这些资源的代码写入finally块中。
必须注意的是:在finally块中不能抛出异常。JAVA异常处理机制保证无论在任何情况下必须先执行finally块然后再离开try块,因此在try块中发生异常的时候,JAVA虚拟机先转到finally块执行finally块中的代码,finally块执行完毕后,再向外抛出异常。如果在finally块中抛出异常,try块捕捉的异常就不能抛出,外部捕捉到的异常就是finally块中的异常信息,而try块中发生的真正的异常堆栈信息则丢失了。
请看下面的代码:

运行程序后,调用者得到的信息如下
java.lang.NullPointerException
at myPackage.MyClass.method1(methodl.java:266)
而不是我们期望得到的数据库异常。这是因为这里的con是null的关系,在finally语句中抛出了NullPointerException,在finally块中增加对con是否为null的判断可以避免产生这种情况。

丢失的异常

请看下面的代码:

上面method2的代码中,try块捕获method1抛出的数据库异常SQLException后,抛出了新的自定义异常MyException。这段代码是否并没有什么问题,但看一下控制台的输出:
MyException:发生了数据库异常:对象名称'MyTable' 无效。
at MyClass.method2(MyClass.java:232)
at MyClass.method3(MyClass.java:255)
原始异常SQLException的信息丢失了,这里只能看到method2里面定义的MyException的堆栈情况;而method1中发生的数据库异常的堆栈则看不到,如何排错呢,只有在method1的代码行中一行行去寻找数据库操作语句了。
JDK的开发者们也意识到了这个情况,在JDK1.4.1中,Throwable类增加了两个构造方法,public Throwable(Throwable cause)和public Throwable(String message,Throwable cause),在构造函数中传入的原始异常堆栈信息将会在printStackTrace方法中打印出来。但对于还在使用JDK1.3的程序员,就只能自己实现打印原始异常堆栈信息的功能了。实现过程也很简单,只需要在自定义的异常类中增加一个原始异常字段,在构造函数中传入原始异常,然后重载printStackTrace方法,首先调用类中保存的原始异常的printStackTrace方法,然后再调用super.printStackTrace方法就可以打印出原始异常信息了。可以这样定义前面代码中出现的MyException类:

架构君码字不易,如需转载,请注明出处:https://javajgs.com/archives/36671
0

发表评论