ClassCastException是如何产生的

合集下载

Java异常面试题 33道

Java异常面试题 33道

Java异常架构与异常关键字1. Java异常简介Java异常是Java提供的一种识别及响应错误的一致性机制。

Java异常机制可以使程序中异常处理代码和正常业务代码分离,保证程序代码更加优雅,并提高程序健壮性。

在有效使用异常的情况下,异常能清晰的回答what, where, why这3个问题:异常类型回答了“什么”被抛出,异常堆栈跟踪回答了“在哪”抛出,异常信息回答了“为什么”会抛出。

2. Java异常架构1. ThrowableThrowable 是 Java 语言中所有错误与异常的超类。

Throwable 包含两个子类:Error(错误)和 Exception(异常),它们通常用于指示发生了异常情况。

Throwable 包含了其线程创建时线程执行堆栈的快照,它提供了 printStackTrace() 等接口用于获取堆栈跟踪数据等信息。

2. Error(错误)定义:Error 类及其子类。

程序中无法处理的错误,表示运行应用程序中出现了严重的错误。

特点:此类错误一般表示代码运行时 JVM 出现问题。

通常有 Virtual MachineError(虚拟机运行错误)、NoClassDefFoundError(类定义错误)等。

比如 OutOfMemoryError:内存不足错误;StackOverflowError:栈溢出错误。

此类错误发生时,JVM 将终止线程。

这些错误是不受检异常,非代码性错误。

因此,当此类错误发生时,应用程序不应该去处理此类错误。

按照Java惯例,我们是不应该实现任何新的Error子类的!3. Exception(异常)程序本身可以捕获并且可以处理的异常。

Exception 这种异常又分为两类:运行时异常和编译时异常。

运行时异常定义:RuntimeException 类及其子类,表示 JVM 在运行期间可能出现的异常。

特点:Java 编译器不会检查它。

也就是说,当程序中可能出现这类异常时,倘若既"没有通过throws声明抛出它",也"没有用try-catch语句捕获它",还是会编译通过。

Java开发中的常见错误及解决方法

Java开发中的常见错误及解决方法

Java开发中的常见错误及解决方法在Java开发中,开发者可能会遇到许多常见的错误。

这些错误可能来自于语法错误、逻辑错误或者编码风格等不同的方面。

今天,我们就来一起探讨Java开发中常见的错误以及如何解决这些问题。

一、空指针异常(NullPointerException)空指针异常是一个极为常见的错误,很容易发生。

这个错误通常发生在访问一个空对象或者调用一个空对象的方法时发生。

在Java中,如果变量没有被初始化或者设置为null,其值就为空。

解决方案:1. 检查变量是否被正确初始化或者设置为null;2. 使用if判空语句来避免空指针异常的发生;3. 使用Objects类中的requireNonNull方法,可以在变量为空的时候抛出异常,防止出现空指针异常的情况,例如:public void showData(String data){Objects.requireNonNull(data,"data must not be null");//do something...}二、数组越界异常(ArrayIndexOutOfBoundsException)如果在访问数组时访问了数组的不存在的元素,或者使用负数的下标来访问数组,就会抛出数组越界异常。

对于数组的访问,必须保证数组下标越界。

解决方案:1. 检查数组下标是否越界;2. 尽可能使用for-each循环,可以保证不会越界;三、类型转换异常(ClassCastException)类型转换异常是因为试图将一个对象转换为不相关的对象类型而导致的异常。

在Java中,如果试图将一个子类实例转换为父类对象时,不需要进行任何显式的类型转换操作。

但是,将一个父类实例转换为一个子类时,就需要使用强制类型转换操作。

解决方案:1. 确保转换类型之前,先用instanceof判断对象类型;2. 避免在不相关对象类型之间进行强制类型转换操作;四、算术异常(ArithmeticException)算术异常通常发生在程序试图除以0的情况下。

Java常见异常(RuntimeException)详细介绍并总结

Java常见异常(RuntimeException)详细介绍并总结

Java常见异常(RuntimeException)详细介绍并总结本⽂重在Java中异常机制的⼀些概念。

写本⽂的⽬的在于⽅便我很长时间后若是忘了这些东西可以通过这篇⽂章迅速回忆起来。

1. 异常机制1.1 异常机制是指当程序出现错误后,程序如何处理。

具体来说,异常机制提供了程序退出的安全通道。

当出现错误后,程序执⾏的流程发⽣改变,程序的控制权转移到异常处理器。

1.2 传统的处理异常的办法是,函数返回⼀个特殊的结果来表⽰出现异常(通常这个特殊结果是⼤家约定俗称的),调⽤该函数的程序负责检查并分析函数返回的结果。

这样做有如下的弊端:例如函数返回-1代表出现异常,但是如果函数确实要返回-1这个正确的值时就会出现混淆;可读性降低,将程序代码与处理异常的代码混爹在⼀起;由调⽤函数的程序来分析错误,这就要求客户程序员对库函数有很深的了解。

1.3 异常处理的流程1.3.1 遇到错误,⽅法⽴即结束,并不返回⼀个值;同时,抛出⼀个异常对象1.3.2 调⽤该⽅法的程序也不会继续执⾏下去,⽽是搜索⼀个可以处理该异常的异常处理器,并执⾏其中的代码2 异常的分类2.1 异常的分类2.1.1 异常的继承结构:基类为Throwable,Error和Exception继承Throwable,RuntimeException和IOException等继承Exception,具体的RuntimeException继承RuntimeException。

2.1.2 Error和RuntimeException及其⼦类成为未检查异常(unchecked),其它异常成为已检查异常(checked)。

2.2 每个类型的异常的特点2.2.1 Error体系 Error类体系描述了Java运⾏系统中的内部错误以及资源耗尽的情形。

应⽤程序不应该抛出这种类型的对象(⼀般是由虚拟机抛出)。

如果出现这种错误,除了尽⼒使程序安全退出外,在其他⽅⾯是⽆能为⼒的。

Java的throw和throws

Java的throw和throws
}
catch (Exception e)
{
System.out.println("catch块处理了Rutime异常");
}
}
public static void main(String[] rags)
{
new A().set();
}
}
2、不做任何处理(即交给Java虚拟机处理,处理结果:打印异常跟踪栈信息后终止程序运行),如下文的例子三就没有处理。
1、用try{} catch{}捕获处理抛出的异常,如下class A:
class A
{ void setFra bibliotek) {
try
{
// 抛出一个Runtime异常
// new RuntimeException():构造一个详细信息为null的新运行时异常实例
throw new RuntimeException();
情况二:如果抛出的是Checked异常,则必须处理,也有两种处理方式:=====================================情况二
1、调用抛出了异常的方法时,将这个方法调用语句放入try块中显式捕获该异常,如下文的例子一;
2、将调用这个方法(抛出了异常的方法)的方法用throws声明抛出异常,如下文的例子二。
例子三:throw语句抛出Runtime异常,所在方法可以不理会,不抛出异常==========================================例子三(class D)
import javax.swing.JOptionPane;
class D
{
void set()//-------------与例子二不同处,可以不声明抛出,不做异常处理

ClassCastException错误解析

ClassCastException错误解析

ClassCastException 错误解析现在Java编程中经常碰到ClassCastException 错误,ClassCastException 是 JVM 在检测到两个类型间的转换不兼容时引发的运行时异常。

此类错误通常会终止用户请求。

本模式试图为您提供了解和排除 ClassCastException 错误最常见成因的一些基本要素。

为什么发生此问题?在执行几乎任何子系统(web 容器、EJB、JCA、群集等)的应用程序代码或 WebLogic Server 代码内均可能发生 ClassCastException。

通过转换,可以指示 Java 编译器将给定类型的变量作为另一种变量来处理。

对基础类型和用户定义类型都可以进行转换。

Java 语言规范定义了允许的转换,其中的大多数可在编译时进行验证。

不过,某些转换还需要运行时验证。

如果在此运行时验证过程中检测到不兼容,JVM 就会引发 ClassCastException。

假设有一个 S 类型的对象,我们想把它转换为 T 类型。

S s;…T t = (T) s;如果存在以下情况,上述转换就可能引发 ClassCastException S 与 T 不兼容。

规范规定:“当应用程序代码尝试将某一对象转换为某一子类时,如果该对象并非该子类的实例,JVM 就会抛出ClassCastException。

”以下是一个示例代码,执行该代码时将会引发此类错误:public class TestCCE { public static void main(String args[]) {Object obj = new Object();String s = (String) obj;}}S 类型和 T 类型兼容,但加载时使用了不同的 ClassLoader。

第二个原因实际上是这种错误最常见的原因。

这种情况在诊断上有相当的难度,而且需要对 Java 类加载以及 WebLogic 类加载体系结构方面的基础知识有一定程度的了解。

类型转换异常

类型转换异常

ClassCastException,从字面上看,是类型转换错误,通常是进行强制类型转换时候出的错误。

下面对产生ClassCastException异常的原因进行分析,然后给出这种异常的解决方法。

这种异常是如何产生的呢?举一个比较形象的例子。

Animal表示动物,Dog表示狗,是动物的子类,Cat表示猫,是动物的子类。

看下面的代码:Animal a1 = new Dog(); // 1Animal a2 = new Cat(); // 2Dog a1 = (Dog)a1; //3Dog a2 = (Dog)a2; //4第3行代码和第4行代码基本相同,从字面意思看都是把动物(Animal)强制转换为狗(Dog),但是第4行代码将产生ng.ClassCastException。

原因是你要把一个猫(a2这只动物是猫)转换成狗,而第3行中是把狗转换成狗,所以可以。

从上面的例子看,ng.ClassCastException是进行强制类型转换的时候产生的异常,强制类型转换的前提是父类引用指向的对象的类型是子类的时候才可以进行强制类型转换,如果父类引用指向的对象的类型不是子类的时候将产生ng.ClassCastException异常。

就是上面a1和a2都是动物,但是a1这只动物是一只狗,而a2这只动物是猫,所以要把a1转换成狗可以,因为a1本身就是狗,而a2是一只猫,所以要转换成狗就出错了。

遇到这样的异常的时候如何解决呢?如果你知道要访问的的对象的具体类型,直接转换成该类型即可。

如果不能确定类型可以通过下面的两种方式进行处理(假设对象为o):1、通过o.getClass().getName()得到具体的类型,可以通过输出语句输出这个类型,然后根据类型进行进行具体的处理。

2、通过if(o instanceof 类型)的语句来判断o的类型是什么。

Java中java.lang.ClassCastException异常原因及解决方法

Java中java.lang.ClassCastException异常原因及解决方法

Java中ng.ClassCastException异常原因及解决⽅法通常我们在 OOP 设计中都会使⽤到继承。

但是在继承对象之间的强制转换可能会遇到j ng.ClassCastException异常的错误。

错误的⽇志如下:19:58:25.010 [http-nio-8080-exec-5] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is ng.ClassCastException: class com.oss ng.ClassCastException: class mon.models.response.ListingResponse cannot be cast to class mon.models.response.ListingDetailResponse (mon.models.response.ListingR问题和原因问题和原因这个问题出现的原因就是继承类之间强制转换的错误。

同时这个错误是运⾏时错误,不是编译错误,因此你编译的时候是没有这个错误的。

考察下⾯的代码:Parent b = new parent();Child c = (Child) b ;采⽤该⽅法不能实现对象类型由超类向⼦类的转换。

上⾯的原因是⽗类的对象是由⽗类创建的,然后你尝试将⽗类创建的对象强制转换到⼦类中。

因为⽗类创建的对象和⼦类需要创建的对象分别使⽤不同的地址空间,那在转换的时候将会出现地址空间引⽤的错误,因此 JVM 会认为你将 2 个完全不同类型的对象进⾏转换,这个时候出现上⾯的运⾏时错误。

交行笔试题20130904

交行笔试题20130904
B./usr/Websphere/AppServer/logs
C./usr/Websphere/AppServer
D./usr/Websphere/AppServer/logs/Server1
15.Error与exception有什么区别?
Error表示系统级的错误和程序不必处理的异常,
Exception表示需要捕捉或者需要程序进行处理的异常。
13.领域模型是一组表示__ __,在设计工作中广泛用来启发设计软件对象.B
A.真实世界的概念类
B.虚拟世界的概念类
C.软件部件的模型
D.硬件部件的模型
14.AIX服务上WAS的默认实例的默认server1服务器上的应用出现了JavaCore时,该javaCore文件会存放在哪里?D
A./usr/Websphere
C. SMS能够把长型数据存放到单独的表空间中;DMS不能够把长型数据存放到单独的表空间中。
D. SMS仅在需要时才分配空间;DMS预先分配空间。
3.假定学生关系是S(S#, SNAME,SEX,AGE),课程关系是C (C#, CNAME,TEACHER),学生选课关系是SC(S#, C#, GRADE),要查找选修“COMPUTER”课程的女学生的姓名,将涉及关系(D)
try {
reader.close();
} catch (IOException e1) { }
}
}
}
20.利用Java泛型,申明一个方法get,能根据特定的类型和字符串name,返回对应的类型的对象(不需要实现内部的方法),并使得以下语句成立:
Dog dog = obj.get(Dog.class,”1”);
= "value";
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

问题描述ClassCastException 是JVM 在检测到两个类型间的转换不兼容时引发的运行时异常。

此类错误通常会终止用户请求。

本模式试图为您提供了解和排除ClassCastException 错误最常见成因的一些基本要素。

故障排除请注意,并非下面所有任务都需要完成。

有些问题仅通过执行几项任务就可以解决。

为什么发生此问题?在执行几乎任何子系统(Web 容器、EJB、JCA、群集等)的应用程序代码或WebLogic Server 代码内均可能发生 ClassCastException。

通过转换,可以指示 Java 编译器将给定类型的变量作为另一种变量来处理。

对基础类型和用户定义类型都可以进行转换。

Java 语言规范定义了允许的转换,其中的大多数可在编译时进行验证。

不过,某些转换还需要运行时验证。

如果在此运行时验证过程中检测到不兼容,JVM 就会引发 ClassCastException。

假设有一个 S 类型的对象,我们想把它转换为 T 类型。

如果存在以下情况,上述转换就可能引发 ClassCastExceptionS 与T 不兼容。

规范规定:“当应用程序代码尝试将某一对象转换为某一子类时,如果该对象并非该子类的实例,JVM 就会抛出ClassCastException。

”以下是一个示例代码,执行该代码时将会引发此类错误:∙S 类型和T 类型兼容,但加载时使用了不同的ClassLoader。

第二个原因实际上是这种错误最常见的原因。

这种情况在诊断上有相当的难度,而且需要对Java 类加载以及WebLogic 类加载体系结构方面的基础知识有一定程度的了解。

什么是ClassLoader?ClassLoader 是允许 JVM 查找和加载类的一种 Java 类。

JVM 有内置的ClassLoader。

不过,应用程序可以定义自定义 ClassLoader。

应用程序定义新的 ClassLoader 通常有两个主要目的:∙自定义和扩展JVM 加载类的方式。

例如:增加对新的类库(网络、加密文件等)的支持∙划分JVM 名称空间,避免名称冲突。

举例来说,利用划分技术可同时运行同一应用程序的多个版本(基于空间的划分)。

此项技术在应用程序服务器(如WebLogic Server)内的另一个重要用途是启用应用程序热重新部署,即在不重新启动JVM 的情况下启动应用程序的新版本(基于时间的划分)。

ClassLoader 按层级方式进行组织。

除系统 Boot ClassLoader 外,其它ClassLoader 都必须有父 ClassLoader。

/wls/docs81/programming/classloading.html (English) 中提供了对 WebLogic 类加载体系结构的说明。

理解类加载的关键记住以下内容会有帮助:∙永远无法在同一ClassLoader 中重新加载类:“热重新部署”需要使用新的ClassLoader。

每个类对其ClassLoader 的引用都是不可变的:this.getClass().getClassLoader()∙在加载类之前,ClassLoader 始终会先询问其父ClassLoader(委托模型)。

这意味着将永远无法重写“核心”类∙同级ClassLoader 间互不了解∙由不同ClassLoader 加载的同一类文件也会被视为不同的类,即便每个字节都完全相同。

这是ClassCastException 的一个典型成因。

∙可以使用Thread.setContextClassloader(cl)将ClassLoader 连接到线程的上下文诊断通常可以在服务器的日志和/或客户端获得完整的 ClassCastException 堆栈跟踪。

该堆栈应能使您对涉及的 WebLogic Server 子系统的情况有相当深入的了解。

请根据这些信息确认该问题是否与某个已知 WebLogic Server 问题的情况相符。

如果相符,请使用相应的解决办法。

如果错误与所有已知问题的情况均不相符,则需要做进一步探查。

如果错误出现在您可以编辑和编译源代码的类中,以下方法可能有助于您理解该问题。

假设出现错误的代码行类似于:如果按照转换规则该转换应该有效,但仍然引发了ClassCastException,则可能的情况是:类“bar”和“Foo”是由不同的ClassLoader 加载的。

要验证这一点,请像下面这样拆分该代码行:典型的输出可能与此类似:下一步是探查为什么涉及了不同的ClassLoader。

请执行下列检查清单中的各项检查:∙检查应用程序打包情况,并检查“Foo”是否是使用由不同ClassLoader 加载的不同模块打包而成。

在这方面众所周知的一个成因是Web 应用程序的“prefer-web-inf-classes”功能(请参阅已知的WebLogic 问题)∙检查它正在使用的应用程序代码或某个框架代码是否更改了WebLogic 线程的上下文ClassLoader,且在请求流程期间未将其还原。

如果应用程序代码内有对Thread.setContextClassloader(cl)的调用,就可能存在这种情况。

∙如果上述所有措施均无济于事,请尝试将问题隔离在一个简单的、可重现的测试案例中,然后联系BEA 技术支持部门,以做进一步探查。

已知的WebLogic Server 问题以下汇集了可导致ClassCastException 错误的各种情况,您在使用各种WebLogic 子系统时可能会遇到这些情况。

小程序有关该情况的完整说明,请参考/wls/docs81/applets/usingapplets.html (English)摘要:如果小程序中的WebLogic Server 客户端尝试从ClassLoader 获取某些资源信息,且一并使用了缓存标志和codebase=/bea_wls_internal/classes标志,就可能会抛出ClassCastException。

解决方法:∙在将类路径servlet 用作代码基时,请不要使用“cache_option”和“cache_archive”一类的缓存选项。

∙使用缓存选项时,请不要使用/classes (ClasspathServlet) 做为代码基。

如果要这样做,请先使用归档实用程序打包客户端JAR。

有关此限制的详细信息,请参阅/developer/bugParade/bugs/4648591.html (English)。

JCA Connector有关该情况的完整说明,请参考/wls/docs81/notes/issues.html (English)。

摘要:发出连接请求时,WebLogic Server 会返回一个代理对象,该对象通过资源适配器将连接对象封装后返回到客户端。

WebLogic Server 使用该代理来提供一些功能,帮助应用程序使用WebLogic Server 的“J2EE 连接器体系结构”实现。

这些功能包括(1) 连接泄漏检测功能和(2) 连接请求在启动使用该连接的全局事务之前发出时,推迟XAResource 登记。

如果将连接请求返回的连接对象向原始的Connection类进行了转换,就可能发生ClassCastException。

导致该异常的对象不外乎在连接请求过程中:(1) 资源适配器进行转换时或(2) 客户端进行转换时。

在WebLogic Server 8.1 SP2 中,尝试检测由上述资源适配器情况(1) 导致的ClassCastException。

如果服务器检测到该转换失败,将关闭代理包装器功能,并在连接请求期间返回连接对象(不进行包装)。

服务器会记录一条警告消息,说明代理包装器已被关闭。

出现此类转换故障时,连接泄漏检测和XAResource 推迟登记功能也将被关闭(但当前在控制台监视中并不会就此给出任何指示)。

WebLogic Server 尝试以使用容器管理的安全性的客户端身份检测ClassCastException。

如果要这样做,则部署的资源适配器须定义安全性Credential。

如果客户端在执行转换时发生ClassCastException,可按如下方式修改客户(客户端)代码:解决方法:如果客户端将连接对象转换为MyConnection,而不是将MyConnection 作为实现资源适配器的Connection接口的一个类,请将该对象修改为一个扩展Connection的接口。

实现一个用于实现MyConnection接口的MyConnectionImpl类。

Servlet 动态重新加载有关该情况的完整说明,请参考/wls/docs81/jsp/reference.html (English)摘要:要在会话过程中动态重新加载 servlet 或 JSP,servlet 会话中存储的对象必须是可序列化的。

需要进行序列化是因为,servlet 是使用新的ClassLoader 重新加载的,而这会导致此前加载的所有类(旧版本 servlet 中的类)与使用新的 ClassLoader 加载的所有类(新版本 servlet 类)发生不兼容的情况。

这种不兼容会导致 servlet 返回ClassCastException 错误。

使用Prefer-web-inf-classes 功能有关该情况的完整说明,请参考/wls/docs81/programming/classloading.html (English)摘要:weblogic.xml Web 应用程序部署描述符包含一个prefer-web-inf-classes 元素(container-descriptor 元素的子元素)。

缺省情况下,此元素设置为False。

如果将此元素设置为True,则不遵循ClassLoader 委托模型,从而使Web 应用程序中的类定义的加载顺序优先于更高级别的ClassLoader 中的类定义。

这样Web 应用程序就可使用其自己版本的第三方类,该类也可能是WebLogic Server 的一部分。

请参阅weblogic.xml Deployment Descriptor Elements (English)。

使用该功能时,必须注意不要混淆使用Web 应用程序的类定义创建的实例与使用服务器的定义创建的实例。

如果混淆了此类实例,就会发生ClassCastException。

群集:在http 会话中存储包含EJBObject 的自定义对象- CR102119摘要:可序列化的自定义对象会包装EJBObject(对EJB 的引用)。

该自定义对象存储在http 会话中。

会话复制时,这种设计就会导致ClassCastException。

相关文档
最新文档