Stepping over a method

Hi all,

Is it possible in any version of IDEA, when debugging some Java code, to
completely skip a method? i.e. not just step over it, but just not
execute it? Or is it a limitation of the Java language and/or debugging
interface that makes this impossible?

Thanks,

Nick.

7 comments

Project Properties | Debugger. There is a check box for "Do not step into
classes". You can add additional classes. Mine has com.sun., java.,
javax.*, etc.

"Nick Atkins" <natkins@slippytoad.com> wrote in message
news:bqodqf$cqo$1@is.intellij.net...

Hi all,

>

Is it possible in any version of IDEA, when debugging some Java code, to
completely skip a method? i.e. not just step over it, but just not
execute it? Or is it a limitation of the Java language and/or debugging
interface that makes this impossible?

>

Thanks,

>

Nick.



0

Excuse me, but doesn't "Do not step into classes" just mean that the debugger will not stop in any lines in the specified classes?

I'm sure that the methods on these classes are still executed.

So this is not what Nick was after. But there may very well be a limitation in the JDK debugger API that makes it impossible for IntelliJ to offer the requested feature. Similarly, there is not way to set the execution point within an active scope, which has also been requested. A feature request was filed 3 weeks ago with Sun for improved debugging support in future JDK versions, but it has not been acknowledged yet.

Regards,
Lars Ugleberg

0

My bad, I totally missed that detail.

Why on earth would he want that??? That is the whole point of code. I
can't imagine how a debugger would be coded to skip statements. What would
happen to program flow. Isn't that the point of debugging.

I am not aware of any language that supports that capability.


"Lars Ugleberg" <lars.ugleberg@inspire.se> wrote in message
news:21301091.1070604837720.JavaMail.javamailuser@localhost...

Excuse me, but doesn't "Do not step into classes" just mean that the

debugger will not stop in any lines in the specified classes?
>

I'm sure that the methods on these classes are still executed.

>

So this is not what Nick was after. But there may very well be a

limitation in the JDK debugger API that makes it impossible for IntelliJ to
offer the requested feature. Similarly, there is not way to set the
execution point within an active scope, which has also been requested. A
feature request was filed 3 weeks ago with Sun for improved debugging
support in future JDK versions, but it has not been acknowledged yet.
>

Regards,
Lars Ugleberg



0

"Norris Shelton" <nshelton@appriss.com> wrote in message
news:bqqbp0$dvn$1@is.intellij.net...

I am not aware of any language that supports that capability.


setIP command in Visual Studio C++ debugger does precisely this. I don't
know about java debugger API though.
Eugene


0

Norris Shelton wrote:

Why on earth would he want that??? That is the whole point of code. I
can't imagine how a debugger would be coded to skip statements. What would
happen to program flow. Isn't that the point of debugging.

I'd want that because in certain situations I'm in I want to see what
would happen if I didn't execute the close() method on an IMAP folder.
I agree it could result in strange side effects but sometimes you just
want to see what those effects would be. Some would say it's just
lazyness as I can simply comment the line out, rebuild and retest.
However, as Evgueny said is his reply, it's a feature available in
Visual C++ (in fact it was a VC++ person working with me who asked if it
was possible!) but is probqably just not supported in the Java debugging
interface.

Otherwise, the debugging tools are great, except for the "suspend
threads" feature which doesn't seem to work properly.

Cheers,

Nick.

0

No, it's not possible to change the "instruction pointer" (IP) in a JVM as it is in Visual C++. The JVM debug API doesn't give the debugger the option of moving the IP. I doubt that Sun would want to provide it, anyway.

There are substantial differences between moving the instruction pointer in Visual C++ and doing it in a JVM.

For one thing, with Visual C++ you can disassemble the Pentium instructions, so you have fine-grain control over which instruction to skip or execute. In Java, you'd have to see the pcode (as javap creates it), and the debugger doesn't provide it.

Secondly, when you change the IP address in Visual C++, you take responsibility for keeping the stack frame intact. If something has been pushed onto the stack and you skip a method call that would remove it, you have to manually adjust the stack pointer or find a "POP" instruction that you can execute repeatedly. In other words, you have complete knowledge of how the processor operates in its environment. But you also have complete responsibility to ensure that the state resulting from changing the IP address is still valid.

But in a JVM, the machine is virtual. Implementations can vary. All JVM's would have to adopt a "virtual processor" whose behavior was known and documented. (Or perhaps there would be a special "debugging JVM" whose behavior was invariant -- no JIT compiling or other optimizations, for example. Closest we come to that today is running the JVM with -classic.) In any case, there is no requirement at present to implement JVM internals in a particular way. That makes it hard to know how to control the internal state and keep it valid.

What Visual C++ provides with the "Set Next Statement" capability is just a lookup of the address of the next statement followed by changing the instruction pointer. You still have responsibility to make sure that the next statement makes sense -- ie. it's not in a different method or different stack context.

It might be feasible to implement a "skip next statement" in the JVMDI (debugging interface). It would only make sense when the stack context wouldn't change as a result of executing the statement. Practically speaking, this would probably have to be done as a JSR because (a) I don't think Sun has the motivation to provide this; after all, they've already given us HotSwap :) (b) this means a change in the JVMDI and that means that all the JVM implementors need a say in it; and (c) there are probably a lot of variants people would want, maybe security issues, and so on. One capability I would like is "pretend the conditional for the 'if' statement is false and take the 'else' branch." Easily done when you have direct control of the IP. Less simple when the conditional is a method call, not a simple boolean (otherwise you'd just set the value of the boolean to false and single step.)

Oh, well -- FWIW,
-Dave

0

I have an idea how to to implement 'set next statement feature'.
1. Pop current frame from the stack
2. Hotswap new method body that will be started with jump command that transfers control to the needed statement.
3. Execute 'stepinto' debugger command.

It's not quite clear how to deal with other calls to this method, but I don't think it's a great problem.


0

Please sign in to leave a comment.