Java:异常本身为空 [英] Java: Exception itself is null
问题描述
我很困惑.是安卓的问题还是Java本身的问题?
当我调试一个与蓝牙一起工作的 Android 应用程序时，流程停止在 IOException 的 catch 块上，我后来发现异常 e 为空......它被抛出时我试图从 InputStream 中读取数据.
是的，它不是 NullPointerException，而是其他类型的 null 异常 - 最好说抛出未初始化.
有可能吗?在什么情况下可以抛出这种单元化的异常?
有可能吗?在什么情况下可以抛出这种单元化的异常??
使用符合标准的 Java 编译器和符合标准的 Java 虚拟机，以及通过扩展符合标准的 Dalvik 虚拟机.JLS 不允许 e 变量在该位置为 null
要么是您的虚拟机有问题，要么是调试器有问题，或者您的 IDE、构建工具和/或进程有问题.
如果我处于您的情况，我会停止现在使用调试器，并退回到向您的代码添加老式跟踪记录.并确保您从源代码进行干净且完整的构建.
<小时>您应该考虑的另一种可能性是 JRE 在运行时报告的行号(以及调试器所依赖的行号)与源代码中的行号不一致.如果您在构建和部署过程中犯了错误，则可能会发生这种情况.错误可能类似于忘记保存文件、忘记构建、忘记部署应用的新版本或使您的 IDE 与文件系统不同步.
<小时>就其价值而言，理论是这是由 throw null; 或等效的东西引起的.JLS 部分 14.18 说:><块引用>
如果表达式的计算正常完成，产生一个空值，那么将创建一个 NullPointerException 类的实例 V' 并抛出而不是空."
如果你在上下文中阅读这句话会更容易理解，但它清楚地说throw null;实际上抛出了一个NullPointerException.
更新
我在这个堆栈溢出问题中找到了另一个合理的解释:异常总是为空一个>
基本上，它是说模拟代码抛出了一个 Eclipse 不知道的异常，而 Eclipse 模拟器有帮助地"替换了 null.这听起来像是一个模拟器错误.
I am pretty confused. Is it an Android problem or a problem with Java itself?
When I was debugging an Android application which works with Bluetooth, the flow stopped on an catch block of IOException in which I later found out that exception e was null.... It was thrown when I was trying to read from an InputStream.
Yes, it was not a NullPointerException, but some other kind of exception which is null - better say thrown un-initialized.
Is it possible? In which scenario can such unitialized exceptions be thrown?
Is it possible? In which scenario such unitialized exceptions can be thrown??
This is not possible using a conformant Java compiler and conformant Java virtual machine, and by extension a conformant Dalvik virtual machine. The JLS doesn't allow the e variable to be null at that location
Either you've got a buggy virtual machine, a buggy debugger, or a problem with your IDE, build tools and / or process.
If I was in your situation, I'd stop using the debugger for now, and fall back on adding old-fashioned traceprints to your code. And make sure that you do a clean and full build from source.
One other possibility you should consider is that the line numbers that the JRE is reporting at runtime (and that the debugger is relying on) are not lining up with the line numbers in the source code. This could happen if you've made a mistake in your build and deployment processes. The mistake might be something like forgetting to save a file, forgetting to build, forgetting to deploy the new version of the app or getting your IDE out of sync with the filesystem.
For what it's worth, the theory is that this is caused by throw null; or something equivalent doesn't hold water. The JLS section 14.18 says:
"If evaluation of the Expression completes normally, producing a null value, then an instance V' of class NullPointerException is created and thrown instead of null."
It is easier to understand if you read that sentence in its context, but it is saying clearly that throw null; actually throws a NullPointerException.
UPDATE
I found another plausible explanation in this Stack Overflow question: Exception is always NULL
Basically, it is saying that the emulated code is throwing an exception that Eclipse doesn't know about, and the Eclipse emulator is "helpfully" substituting a null. That sounds like an emulator bug.
这篇关于Java:异常本身为空的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
