JDIType.throwDebugException() doesn't properly handle disconnected exception

[iloveeclipse]

In our automated tests we see sometimes logged errors like:

junit.framework.AssertionFailedError: 1 unexpected error(s) or warning(s) found in the log. Messages: [Internal error logged from JDI Debug: ]. First error or warning: Internal error logged from JDI Debug: . 
Stack:com.sun.jdi.VMDisconnectedException: Got IOException from Virtual Machine
	at org.eclipse.jdi.internal.connect.PacketSendManager.sendPacket(PacketSendManager.java:93)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:190)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:230)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:262)
	at org.eclipse.jdi.internal.ClassTypeImpl.superclass(ClassTypeImpl.java:309)
	at org.eclipse.jdt.internal.debug.core.model.JDIClassType.getSuperclass(JDIClassType.java:145)

The test doesn't expect that error in the log and fails (but would succeed without error log entry).
The error itself is unconditionally logged by the framework even if the debug listener works just fine & properly handles the case if the debug target is gone.

The error is logged because in JDIDebugElement.logError()

eclipse.jdt.debug/org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/model/JDIDebugElement.java

Line 56 in 0c8c6d9

protected void logError(Exception e) {

the getDebugTarget().isAvailable() says "yes, I'm still there" even if JVM is already disconnected.

The root cause of it is a subtle difference between JDIType.throwDebugException() and JDIDebugElement.throwDebugException(): the overridden method in JDIType doesn't call JDIDebugElement.disconnected(), so after JDIType.throwDebugException() is called above with VMDisconnectedException in JDIClassType.getSuperclass() debug target is still assuming that JVM is connected.

eclipse.jdt.debug/org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/model/JDIType.java

Line 77 in 0c8c6d9

protected void throwDebugException(String message, int code,

The problem was introduced long time ago:

• The original JDIDebugElement code was copy/pasted to JDIType and at that time original code did not had yet disconnected() call, see this commit.
• Same year later the original code in JDIDebugElement was "cleaned up" and disconnected() call was added, but only in original code, not in the copied code, see this commit.
• One year later JDIType refactoring happened where JDIType extended JDIDebugElement see this commit but the method was already there and nobody noticed the small difference.

What we learn: copy/paste is root of all evil.

I will provide a patch.