JDK-4460188 : JDI spec: spec for global RuntimeExceptions inconsistent - centralize it
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.3.1,1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,linux,solaris,solaris_7,solaris_8,solaris_9,windows_nt generic,linux,solaris,solaris_7,solaris_8,solaris_9,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 2001-05-17
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 beta2Fixed
Related Reports
Duplicate :  
JDK-4464724 - /nsk/jdi tests throw NullPointerException- jdi.Connector.BooleanArgument.isValid
Duplicate :  
JDK-4432051 - JDI spec: methods which throw NullPointerException on null param not documented
Duplicate :  
JDK-4394613 - JDI spec: ReferenceType.equals() does not throw any Exception for unloaded class
Duplicate :  
JDK-4331535 - JDI: some VirtualMachine methods do not throw VMDisconnectedException
Description
Two problems --

First, the following RuntimeExceptions are spec'ed to be thrown in only
some of the places where they can be:

  ObjectCollectedException
  VMDisconnectedException
  VMMismatchException
  VMOutOfMemoryException
  NullPointerException

Spec should be consistent.

Second, some exceptions (specifically, ObjectCollectedException
and VMDisconnectedException) are not always thrown by methods which
are spec'ed to throw them.  Exception is not thrown because no 
interaction with target VM is needed (e.g., info is cached).
They should be specified that the exception "may" be thrown.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
PUBLIC COMMENTS Two problems -- First, the following RuntimeExceptions are spec'ed to be thrown in only some of the places where they can be: ObjectCollectedException VMDisconnectedException VMMismatchException VMOutOfMemoryException NullPointerException Spec should be consistent. Second, some exceptions (specifically, ObjectCollectedException and VMDisconnectedException) are not always thrown by methods which are spec'ed to throw them. Exception is not thrown because no interaction with target VM is needed (e.g., info is cached). They should be specified that the exception "may" be thrown. ====== This bug had been fixed. The exceptions are now documented globally in jdi-overview.html. jamie.ho@Eng 2001-06-11
11-06-2001
SUGGESTED FIX A fix related to this has been put into VirtualMachineImpl.java. That fix turns the validateVM() method into a NOP. This means that VMDisconnectedException won't be thrown unless an attempt is actually made to communicate with the debuggee, and the debuggee is gone. james.holmlund@Eng 2001-05-30
30-05-2001
EVALUATION Within the JDI spec the documentation for where the most global exceptions (VMMismatchException, VMDisconnectedException, ObjectCollectedException and NullPointerException) are thrown is highly inconsistent; they are documented in someplaces and not in others. The SDK docs are inconsistent as well in similiar cases (NullPointerException). I would like the spec to be consistent, there seems to be two options: [1] Document them for each method [2] Document them centrally Option [1] would severely clutter the spec (which is why the SDK for the most part does not document NullPointerException). Thus is believe [2] is the correct approach. I propose that roughly the text below be added to the JDI package doc and also specifically mentioned in the referenced interface. A second issue, having to do with these exceptions, is that there is no advantage to the JDI user in promising that a timing related exception (VMDisconnectedException and ObjectCollectedException) will be thrown, so I propose "may throw". Note: since null is the mirror for null, some methods will need to specifically mention that null is a valid parameter: *.setValue - value or is a valid element in the List parameter: *.setValues - values *.invokeMethod and *.newInstance - arguements Also note: centralization means that any existing mention of these exception (in the specified interfaces) should be removed. Existing exceptions not in the specified interfaces should be brought to my attention. So there are three actions that must be taken: 1) Include a version of the below (converted to understandable English) in the JDI overview document 2) The applicable sections (editted) should be added to the specified interfaces. For example, ObjectReference should have: Any method on ObjectReference or which directly or indirectly takes ObjectReference as parameter may throw VMDisconnectedException if the target VM is disconnected and the VMDisconnectEvent has been or is available to be read from the EventQueue. Any method on ObjectReference or which directly or indirectly takes ObjectReference as parameter may throw VMOutOfMemoryException if the target VM has run out of memory. Any method on ObjectReference or which directly or indirectly takes ObjectReference as parameter may throw ObjectCollectedException if the mirrored object has been garbage collected. 3) Existing references should be removed. I think 1) and 2) should be put in an "Exceptions:" section so they can be easily found/ignored as needed. ---------------------------------------------- Any method on a Mirror that takes a Mirror as an parameter directly or indirectly (e.g., as a element in a List) will throw VMMismatchException if the mirrors are from different virtual machines. Any method which takes a java.lang.Object as an parameter will throw NullPointerException if a null is passed directly or indirectly - unless null is explicitly mentioned as a valid parameter. The exceptions below are not guaranteed to be thrown except in the case that not doing so would return an incorrect result. Any method on ObjectReference, ReferenceType, EventRequest, StackFrame, or VirtualMachine or which takes one of these directly or indirectly as an parameter may throw VMDisconnectedException if the target VM is disconnected and the VMDisconnectEvent has been or is available to be read from the EventQueue. Any method on ObjectReference, ReferenceType, EventRequest, StackFrame, or VirtualMachine or which takes one of these directly or indirectly as an parameter may throw VMOutOfMemoryException if the target VM has run out of memory. Any method on ObjectReference or which directly or indirectly takes ObjectReference as parameter may throw ObjectCollectedException if the mirrored object has been garbage collected. Any method on ReferenceType or which directly or indirectly takes ReferenceType as parameter may throw ObjectCollectedException if the mirrored type has been unloaded. robert.field@Eng 2001-05-17 This bug had been fixed. The exceptions are now documented globally in jdi-overview.html. jamie.ho@Eng 2001-06-11
17-05-2001