This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 57442 - Support Method exit breakpoints and examination of normal return value or excptional return Throwable
Summary: Support Method exit breakpoints and examination of normal return value or exc...
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: UI
Depends on:
Blocks: 89617
  Show dependency tree
 
Reported: 2005-04-04 18:00 UTC by _ sandipchitale
Modified: 2010-04-29 09:21 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ sandipchitale 2005-04-04 18:00:23 UTC
Many times a method returns from multiple places. Sometimes the method returns 
with exception. The debugger should support a short cut mechanism to set a 
breakpoint on method exit - normal or exceptional.

In case of normal exit it should be possible to examine the return value.
In case of exception it should be possible to examine the Throwable. I guess 
this is achievable with an java.lang.Throwable exception breakpoint, however 
what I am asking for should be limited to that particual method's scope only.

I think JPDA - JVMDI and JVMTI both have support for achieving this.
Comment 1 Jan Jancura 2005-04-05 08:21:28 UTC
Good idea.
Comment 2 Roman Ondruska 2005-05-10 16:45:55 UTC
Yes, this could be useful. Should be considered.
Comment 3 Martin Entlicher 2005-12-12 16:59:12 UTC
This is already supported in JDK 1.6. Scheduling for NetBeans 5.1.
Comment 4 Martin Entlicher 2006-07-10 11:29:36 UTC
Unfortunately, NetBeans debugger does not use the method enter/exit breakpoints
at all. It stops at the appropriate location instead. We need to reimplement the
method breakpoint first to use the MethodEntryRequest/MethodExitRequest.
Comment 5 Martin Entlicher 2006-07-10 12:03:29 UTC
This will require the change of the Method breakpoint dialog.
Current UI:
Package Name: [___________________]
Class Name:   [___________________]
[x] Apply Also to Anonymous Inner Classes
[ ] All Methods for Given Classes
Method Name:  [___________________]
Condition:    [___________________]

===

We'll add a possibility to stop on entry/exit and remove "Apply Also to
Anonymous Inner Classes" since it's not implemented.

The proposed new UI is:
Package Name: [___________________]
Class Name:   [___________________]
[ ] All Methods for Given Classes
Method Name:  [___________________]
[x] Stop On Method Entry
[ ] Stop On Method Exit
Condition:    [___________________]

Any comments?
Comment 6 Jiri Kovalsky 2006-07-10 12:36:13 UTC
I like the proposed solution.
Comment 7 _ sandipchitale 2006-07-10 15:51:20 UTC
I am looking forward to this enhancement :)

A couple more points:

1. The UI seems to allow only the method name. So what happens in case of 
overloaded methods? Which one of the overloaded methods is selected? In other 
words shouldn't the method signature be considered when setting the 
breakpoint? So instead of using a text field for the user to enter the method 
signature use a Select... button which pops up a method selection dialog for 
the give class name. This Select... button should be enabled only when a valid 
package and class name has been entered.

2. Will it be possible to set the method entry/exit breakpoint using a context 
menu on method nodes in the Projects window as well as Navigator window i.e. 
where ever a method appears as an explorer node.

3. Will this new implementation allow examination of return value in case of 
normal return? Will it allow examination of the Throwable in case of 
exceptional return? Where will these values to visible? In the local variables 
view - may be special first level nodes such as  "Return Value" 
or "Throwable"? Similarly will these values be available for logging using the 
{$returnValue} or some such syntax in the "Print Text" textfield of the 
breakpoint customizer?



If we implement this Netbeans debugger will be the first one to do this :)
Comment 8 Martin Entlicher 2006-07-10 18:36:33 UTC
Ad 1) Currently all overloaded methods are hit.
      The textfield for the method name is still important, because '*' wildcard
      is recognized. But the idea with the method signature is interesting, it
      can be compared with com.sun.jdi.Method.argumentTypeNames(). We can add
      the Select button for that.

Ad 2) There is issue #43066. It needs to be consulted with and approved by HIE.

Ad 3) It will definitelly allow examination of return value, we plan to add this
      into Local Variables Window. See issue #41113. It's good that you've
      mentioned the {$returnValue} for logging, it will be added as well.
      The problem is, that MethodExitRequest is not hit if the method terminates 
      with a thrown exception. We'd have to create one extra hidden exception
      breakpoint for Throwable, which can hurt performance. IMHO it's better
      when the user uses the Exception breakpoint instead in this case so that
      the behavior is more transparent and there is no hidden work which hurts
      performance. We can consider extending the Exception breakpoint to stop
      only when the exception was thrown from certain classes, but the check
      would not be trivial.
Comment 9 _ sandipchitale 2006-07-10 19:12:48 UTC
Ad 2) One other place I would like to the support for adding method exit 
breakpoint is in the Call Stack view itself.

Ad 3) Instead of adding a hidden Exception breakpoint could you ask the user 
if it is ok to add such a breakpoint in the Method breakpoint customizer.
Something like:

[X] Stop On Method Exit
    [ ] Add an Exception Breakpoint (Throwable) restricted to this method
[Customize...]
 
This choice could be unselected by default, but this UI could provide a 
convinient way for the user to accomplish capturing of method exit - normal or 
exceptional. The Customize... button could launch that Exception Breakpoints 
customizer dialog so that the user can fine tune on which exception they want 
to stop. Or may be this is an overkill?

I wish JDI had a method filter mechanism analogous to 
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/com/sun/jdi/request/Exceptio
nRequest.html#addClassFilter(java.lang.String) on the Exception breakpoints :)
Comment 10 Martin Entlicher 2006-07-10 20:35:26 UTC
Ad 2) O.K. I'll add it into issue #43066. I also like the idea to take the
advantage of running debuggee and suggest setting of instance filter and thread
filter. These could be easily pre-filled from the Call Stack view. This is sort
of advanced functionality and we can track it as a separate issue. Though I did
not get requests for this from our users yet.

Ad 3) O.K. We'll consider this and discuss with HIE. I don't want the UI to be
too complex. This will require API enhancement, so it takes some time to
implement anyway. It can be added as a second phase of this issue...

I also do not know why they did not add a filter for method names and/or Method
instances. I'll submit a RFE for JDI, I did not find anything like that in query
for JDI RFEs.

BTW: After rewrite to MethodEntryRequests, breakpoints for abstract and native
methods will start to work.
Comment 11 Martin Entlicher 2006-07-11 15:54:12 UTC
I've submitted a RFE for JDI: 6447614

Support for both method enter and method exit breakpoints is in trunk. The
display of return value will likely require an API change...

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/ClassBasedBreakpoint.java,v
 <--  ClassBasedBreakpoint.java
new revision: 1.14; previous revision: 1.13

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/MethodBreakpointImpl.java,v
 <--  MethodBreakpointImpl.java
new revision: 1.12; previous revision: 1.11

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/Bundle.properties,v
 <--  Bundle.properties
new revision: 1.17; previous revision: 1.16

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/MethodBreakpointPanel.form,v
 <--  MethodBreakpointPanel.form
new revision: 1.6; previous revision: 1.5

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/MethodBreakpointPanel.java,v
 <--  MethodBreakpointPanel.java
new revision: 1.16; previous revision: 1.15
Comment 12 Martin Entlicher 2006-07-21 15:20:46 UTC
The display of method return value is there, see issue #41113.
A special "return" variable name is introduced, which can be used as a reference
to the return value of method provided by method exit breakpoint.

Regarding the possibility to stop when a method is leaved via an exception, I'll
submit a separate enhancement, because this is much more then a siple method
exit breakpoint...

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/expr/Expression.java,v
 <--  Expression.java
new revision: 1.5; previous revision: 1.4

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/Bundle.properties,v
 <--  Bundle.properties
new revision: 1.18; previous revision: 1.17
Comment 13 Martin Entlicher 2006-07-21 15:36:23 UTC
Issue #80837 was created for the detection of a method being left by an exception.
Comment 14 Quality Engineering 2010-04-29 09:21:55 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.