26

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?

An exception is null... Note: it's NOT a null pointer exception!!

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Prasham
  • 6,646
  • 8
  • 38
  • 55
  • Pls. add the code sample throwing exception. – Azodious Dec 06 '11 at 13:35
  • it's Just a BluetoothInputStream.read() call with already connected device... But I am trying to put a snapshot as a proof if anybody is interested...... – Prasham Dec 06 '11 at 13:41
  • @Dimme as an IOException??? or I am catching this null throw on IOException catch block because its written first???? IS IT POSSIBLE??? – Prasham Dec 06 '11 at 13:42
  • 4
    I've seen the debugger get fooled before by outdated code. Try cleaning the project and trying again maybe? – Ian McLaird Dec 06 '11 at 13:49

2 Answers2

17

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

You're probably being fooled by your debugger.

Add another line of code under that line (something useless like if(false) log.v("","");), break there, and check the value of your exception from there.

Also try Log.e(TAG, "my null exception", e);, and read the log.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
tacone
  • 11,371
  • 8
  • 43
  • 60
  • Log should print something about that throwable but probably the throwable is null.... it prints nothing more than "My null exception" – Prasham Dec 06 '11 at 13:56
  • "Being fooled by your debugger" is not necessarily confined to misrepresentation - the debugger could potentially corrupt program flow or state and not simply misreport it. – Chris Stratton May 14 '14 at 17:05