views:

117

answers:

4

In Visual Studio, when debugging, one can drag the execution point (current instruction pointer, yellow dot) to another place in the current method.

This is impossible in IntelliJ, and some have stated it's generally impossible in Java. Why?

+1  A: 

IntelliJ interacts with a running JVM through the standard Java debugging interface, so it can debug programs' against different JDKs. This does not support moving the execution point around as you describe.

It does let you wind the call stack back and perform a method call again. In IntelliJ, use the threads window to select a stack frame of a suspended thread and wind back to it. Then continue the thread to re-call the method at that point in the program.

Note: this will not roll back the state of the objects, so strange effects may occur.

Nat
A: 

Java doesn't have a current execution pointer which can point to a random piece of code. Java assumes the order of execution is in the code, not something you would manipulate.

Perhaps you could explain why you would want to do this and we can let you know another way of achieving the same thing.

Peter Lawrey
It is very helpful to debugging :)
ripper234
Can you give an example?
Peter Lawrey
An example would be when you have a bug in code which prevents you from executing further, but you're not concerned with it at the moment so you just want to skip that part. Or you want to skip a piece of code to see what would happen if it is not executed (e.g. to prove an assumption correct) and you ant to do it without recompiling the whole thing.
axk
The whole idea sounds flawed. You should always be concerned with any bug which prevents execution. The simplest way to skip over code which you want to ignore is to comment it out, or to evaluate an expression which does what you want. If you change the contents of one method your IDE should only re-compile that class, not the whole thing.
Peter Lawrey
A: 

You can tell the debugger to "Run to line" forward.

quant_dev
+1  A: 

In Eclipse, if you edit a method being debugged causing the debugged code to be updated the JVM rolls back execution to the first safe place. Usually this is the first line in that method.

It is very helpful in a debugging scenario.

Thorbjørn Ravn Andersen