空异常 java,Java的：异常本身就是空

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.