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.
Summary: | Support Method exit breakpoints and examination of normal return value or excptional return Throwable | ||
---|---|---|---|
Product: | debugger | Reporter: | _ sandipchitale <sandipchitale> |
Component: | Java | Assignee: | Martin Entlicher <mentlicher> |
Status: | CLOSED FIXED | ||
Severity: | blocker | Keywords: | UI |
Priority: | P2 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 89617 |
Description
_ sandipchitale
2005-04-04 18:00:23 UTC
Good idea. Yes, this could be useful. Should be considered. This is already supported in JDK 1.6. Scheduling for NetBeans 5.1. 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. 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? I like the proposed solution. 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 :) 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. 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 :) 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. 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 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 Issue #80837 was created for the detection of a method being left by an exception. Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier. |