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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…