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: | [67cat] Method return value not displayed by "normal" step through | ||
|---|---|---|---|
| Product: | debugger | Reporter: | ulfzibis <ulfzibis> |
| Component: | Code | Assignee: | issues@debugger <issues> |
| Status: | NEW --- | ||
| Severity: | blocker | ||
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
ulfzibis
2009-05-20 22:11:38 UTC
This can not be a defect, it's a missing functionality, that can be requested as an enhancement. The problem with this is implementation. We have no access to stack content (requested from JDK, but it's not going to be implemented) and I do not want to add the overhead with method exit breakpoint (which is submitted in step out to get the return value) to every step. Method exit breakpoint can be hit too many times, ironically, there's no way to restrict it to a particular method. Due to these facts, this will not be implemented anytime soon. But can't you check the source line where debuggers step cursor (green arrow) is pointing to, and if there is a "return", just execute "Step out", even if "Step over" is invoked from user? Anyway, isn't it ugly to show "After return from ..." item in Variables window, if there is no value? Maybe it should be suppressed in such case. Is there a JDK Bug ID about this? I like to vote on it? I agree with Ulf. If the breakpoint overhead is okay for "step out", I don't see why it shouldn't be okay for "step over". Or if it is a problem, let the user decide by providing an additional "step over with return value". One thing that probably needs to be considered with the breakpoint solution is recursive calls. If the breakpoint is set before the call which is being "stepped over", it needs to be conditional on the stack depth, so that it doesn't trigger on a nested call to the same method. A whole different solution on the JDK level would be for the compiler to have an option to create hidden local variables for intermediate results so that debuggers can inspect them. Of course that's a less attractive solution, and likely problematic for expressions in static initializers and argument expressions to this() and super(). A true JVM- based solution would certainly be better. |