Java的：异常本身就是空 [英] Java: Exception itself is null
问题描述
我是pretty的糊涂了一个Android的问题或Java问题，它的自我。
当我在调试一个Android应用程序，它与蓝牙的工作原理，流停止 IOException异常中，我后来发现例外五是空的catch块上...当我试图从InputStream读取，它被扔
是的，这不是一个 NullPointerException异常但其他类型的异常是空值最好说扔未初始化。
这可能吗？在这情况下，例如未初始化的异常可以被抛出??
这可能吗？在这情况下，例如未初始化的异常可以被抛出??
这是不可能使用一个一致的Java编译器和符合标准的Java虚拟机，并通过扩展一个一致Davlik虚拟机。在JLS不允许电子变量是空在该位置
无论你已经有了一个越野车的虚拟机，车调试器，或与您的IDE中的问题，构建工具和/或处理。
如果我在你的情况，我会停止使用调试器，现在，依傍将老式traceprints到您的code。并确保你从源代码做一个干净，完整的构建。
一，你应该考虑另一种情况是，该JRE在运行时报告的行号（和调试器是依靠）不排队与源$ C $ c中的行号。这可能发生，如果你已经在你的构建和部署过程中犯了一个错误。这个错误可能是这样忘记保存文件时，忘记建立，忘记部署应用程序的新版本，或者让你的IDE不同步文件系统。
FWIW，该理论认为，这是由于掷空; 或等同的东西是站不住脚的。该 JLS第14.18 说：
如果防爆pression评价正常完成，产生一个空值，那么NullPointerException异常类的实例V'是创建和抛出，而不是空。的
这是比较容易，如果你读这句话的上下文理解，但它说清楚，掷空; 居然抛出一个 NullPointerException异常。
更新
我发现了另一个可能的解释在此等问题：异常为NULL总是
基本上，它是说，在模拟code抛出的异常Eclipse不知道，和Eclipse模拟器是有益代以空。这听起来像一个仿真器的bug。
I am pretty confused its an android problem or Java problem it self.
When I was debugging an android application which works with Bluetooth, 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 other kind of exception which is null- Better say thrown un-initialized.
Is it possible? In which scenario such unitialized exceptions can 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 Davlik 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.
FWIW, 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 SO question: Exception is NULL always
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屋！
