Setting breakpoint on the end of the method in Eclipse

D

dt

I have a hard time doing something in Eclipse. I hope I am missing
something obvious, since otherwise I must say this is a very annoying
feature of Eclipse.

Assume the following code:

void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;
// other code here
} // <--- Breakpoint here
} // <--- Breakpoint here

How to set a breakpoint on the lines marked with // <--- Breakpoint
here? When I try this, Eclipse says: "Breakpoint cannot be set at the
given position". In other words, I cannot catch the moment of exit
from the while or method. Yes, putting a dummy boolean dummy = 0; just
before the end of the procedure is a solution - however, much far from
"the" solution. Please, any ideas, comments or suggestions?
 
J

Jason Cavett

I have a hard time doing something in Eclipse. I hope I am missing
something obvious, since otherwise I must say this is a very annoying
feature of Eclipse.

Assume the following code:

void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;
// other code here
} // <--- Breakpoint here

} // <--- Breakpoint here

How to set a breakpoint on the lines marked with // <--- Breakpoint
here? When I try this, Eclipse says: "Breakpoint cannot be set at the
given position". In other words, I cannot catch the moment of exit
from the while or method. Yes, putting a dummy boolean dummy = 0; just
before the end of the procedure is a solution - however, much far from
"the" solution. Please, any ideas, comments or suggestions?

You can't set it because it's not code that can be stopped at. The
Eclipse compiler has no way of halting execution at that ponit.
 
D

dt

You can't set it because it's not code that can be stopped at. The
Eclipse compiler has no way of halting execution at that ponit.
I know there is no user code, but all other languages (e.g. all C-s:
C, C++, C#) and the IDEs I have been working with have this ability.
Why is C# so different in this regard - and you really can stop at the
end of the above-like method. Pardon me, but this really sucks. I
really don't know why (i.e. is it a Java feature, VM feature or
Eclipse feature), but again - it really, really sucks.
 
S

Spring Liu

I know there is no user code, but all other languages (e.g. all C-s:
C, C++, C#) and the IDEs I have been working with have this ability.
Why is C# so different in this regard - and you really can stop at the
end of the above-like method. Pardon me, but this really sucks. I
really don't know why (i.e. is it a Java feature, VM feature or
Eclipse feature), but again - it really, really sucks.

C# compiler insert nop instruction at '}' for debugging, so the
debugger can stop there.
i guss eclipse doesn't have this feature
 
P

Patricia Shanahan

dt said:
I have a hard time doing something in Eclipse. I hope I am missing
something obvious, since otherwise I must say this is a very annoying
feature of Eclipse.

Assume the following code:

void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;
// other code here
} // <--- Breakpoint here
} // <--- Breakpoint here

How to set a breakpoint on the lines marked with // <--- Breakpoint
here? When I try this, Eclipse says: "Breakpoint cannot be set at the
given position". In other words, I cannot catch the moment of exit
from the while or method. Yes, putting a dummy boolean dummy = 0; just
before the end of the procedure is a solution - however, much far from
"the" solution. Please, any ideas, comments or suggestions?

This is a bit indirect, but does not require any source code changes.

Create a breakpoint on the

void test() {

line. Right click the breakpoint indicator, select "Breakpoint
Properties", uncheck "Method Entry" and check "Method Exit".

When the breakpoint is hit, the indicator does point to the final brace.
I have no idea why inserting a breakpoint on the final brace is not
treated as equivalent to this process.

Patricia
 
D

dt

C# compiler insert nop instruction at '}' for debugging, so the
debugger can stop there.
i guss eclipse doesn't have this feature
As you can see from what Patricia wrote, the part about "so the
debugger can stop here" is not true - it can stop on method exit. You
are maybe right about the nop, I don't know, but there should be at
least the option to do this in Eclipse - i.e. to make code with nop
(or however else is possible) for debugging.
This is a bit indirect, but does not require any source code changes.

Create a breakpoint on the

void test() {

line. Right click the breakpoint indicator, select "Breakpoint
Properties", uncheck "Method Entry" and check "Method Exit".

When the breakpoint is hit, the indicator does point to the final
brace.
I have no idea why inserting a breakpoint on the final brace is not
treated as equivalent to this process.

Patricia
<
Thanks Patricia, this worked. Two things - this is "indirect", as you
said. It will certainly help me do what I wanted (my case is simple
enough for the above technique to be applied), but it still sucks and
this will not let you do the other thing - stop on the end of the
while loop. To make it a little clearer:

void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;
// other code here
boolean a = true;
while(b) {
if(otherMethodReturningBoolean())
b = false;
} // <--- Breakpoint here
} // <--- Breakpoint here
} // <--- Breakpoint here

Consider the two extra breakpoint possibilities (excluding method
end). How would you debug the end of while(b), while still staying in
while(a) iteration?

A digression - I tried NetBeans and it works, if I may say, as
expected. Thus, it's not a Java language or Java VM problem - it's an
Eclipse problem. Pardon me again for being so frustrated, but I really
am. I like Eclipse very, very much, but it is missing some really
basic things here and there. Maybe I am not thinking as the rest of
the world, but it seems that the rest of IDE developers think like
me :).

For example, take a look at what is sometimes called "virtual lines" -
being able to position the cursor anywhere on the line, regardless of
whether the line has enough characters for that column to exist. This
really helps when you scroll through the code (at least it helps me),
but Eclipse doesn't support that. Another thing - consider the
keyboard usage. You can use menus to call Search/File... function. Can
you do it using keyboard only? I couldn't find the way - if anyone
knows how to do this, please let me know. However, you can use Ctrl+H
to call Search/Search..., which is in fact Search/Java... option. What
frustrates me even more is that these features are so easy to
implement compared to e.g. real-time error checking, Java code
formatting or some of the numerous features I could list here.

It's like having a car which you couldn't start from inside using a
key, as common today, but you would have to go outside and use a hand
crank. Yes it works, but we have the keys now - get rid of the cranks.
Well, only my 2 cents... Disregard the rant, please - a pure product
of my frustration. Didn't want to offend anyone - if I did, please
forgive me! Let's do something useful.
 
L

Lew

dt said:
Thanks Patricia, this worked. Two things - this is "indirect", as you
said. It will certainly help me do what I wanted (my case is simple
enough for the above technique to be applied), but it still sucks

Well, that certainly is an opinion.

There is no instruction on '}' so there is no place to stop. You whine that
the IDE does not add a "nop" (is there even such an instruction in the JVM?).
I would whine if the IDE changed my code. I prefer breakpoints to exist
only where there is a place to stop, so /my/ opinion is that it does not suck.
and this will not let you do the other thing - stop on the end of the
while loop. To make it a little clearer:

void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;
// other code here
boolean a = true;
while(b) {
if(otherMethodReturningBoolean())
b = false;
} // <--- Breakpoint here
} // <--- Breakpoint here
} // <--- Breakpoint here

Consider the two extra breakpoint possibilities (excluding method
end). How would you debug the end of while(b), while still staying in
while(a) iteration?

Put the breakpoint on the "while ( b )" line.

Right before the first instruction of a loop is the same spot as right after
the last.

You get one extra stop, which can be eliminated with a conditional breakpoint
if it bothers you that much.

You will also need to set a breakpoint on the first instruction after the
loop, which in your case is the "while ( a )" instruction.

With the breakpoint on method exit you now have everything you asked for. It
no longer sucks, does it?
 
L

Lew

dt said:
void test() {
boolean a = true;
while(a) {
if(otherMethodReturningBoolean())
a = false;

If it's returning boolean, why not just assign to a?
// other code here
boolean a = true;

Did you mean "boolean b = true;"?
while(b) {
if(otherMethodReturningBoolean())
b = false;
} // <--- Breakpoint here
} // <--- Breakpoint here
} // <--- Breakpoint here

Since you want to guarantee at least one iteration for the "b" loop, couldn't
a better idiom be the do ... while() loop?

void test()
{
boolean a;
do
{
a = ! otherMethodReturningBoolean();
doOtherStuff();

boolean b;
do
{
b = ! yetAnotherMethodReturningBoolean();
doStillOtherStuff();
} while ( b ); // BTW you can put a breakpoint here
} while ( a ); // BTW you can put a breakpoint here, too
}
 
L

Lew

Lew said:
void test()
{
boolean a;
do
{
a = ! otherMethodReturningBoolean();
doOtherStuff();

boolean b;
do
{
b = ! yetAnotherMethodReturningBoolean();
doStillOtherStuff();
} while ( b ); // BTW you can put a breakpoint here
} while ( a ); // BTW you can put a breakpoint here, too
}

To restrict the scope of the booleans you could use for ( ... ).

void test()
{
for ( boolean a = true; a; )
{
a = ! otherMethodReturningBoolean();
doOtherStuff();

for ( boolean b = true; b; )
{
b = ! yetAnotherMethodReturningBoolean();
doStillOtherStuff();
}
}
}

Now your breakpoints are on the "for" lines.
 
P

Patricia Shanahan

Lew said:
Well, that certainly is an opinion.

There is no instruction on '}' so there is no place to stop. You whine
that the IDE does not add a "nop" (is there even such an instruction in
the JVM?). I would whine if the IDE changed my code. I prefer
breakpoints to exist only where there is a place to stop, so /my/
opinion is that it does not suck.
....

There IS something at the closing brace of a method that can complete
normally. The JVM does not magically intuit the need to pop a stack
frame and jump to the caller's code. It executes a return instruction.

The fact that Eclipse does implement break on method exit proves that it
can do so. The issue is not one of executable program structure or
virtual machine capability, but of user interface.

Which is the better representation of the idea of break on fall through
to the end of the method?

1. Click on the closing brace line.

2. Click on the start of the method declaration to create a break on
method entry, then edit its properties to turn it into a break on method
exit.

Patricia
 
D

dt

Lew, thanks for a reply.
Well, that certainly is an opinion. Certainly.

There is no instruction on '}' so there is no place to stop. You whine that
the IDE does not add a "nop" (is there even such an instruction in the JVM?).
There is NOP in Java VM:
http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc.html
I would whine if the IDE changed my code. I prefer breakpoints to exist
only where there is a place to stop, so /my/ opinion is that it does not suck.
I agree with the "code change" part. I disagree that the method exit
is not a place at which you would like to stop.
Put the breakpoint on the "while ( b )" line.
Right before the first instruction of a loop is the same spot as right after
the last.
Not true. Try this code in Eclipse:

public void breakpointTest() {
int a = 0;
while(a < 100) {
a++;
if(a == 1)
break;
}
}


and try to put a breakpoint on while - it will be reached once (the
one time you list as "one extra stop") and that's it. To be honest,
even NetBeans doesn't stop here. I don't know about the other IDEs
(e.g. VisualStudio for C# or so), but if I test them, I'll report it.
You get one extra stop, which can be eliminated with a conditional breakpoint
if it bothers you that much.
It's far from one extra stop:

public void breakpointTest() {
int a = 0;
while(a < 100) {
a++;
if(a == 10)
break;
}
}

If you put a breakpoint at while, it will stop 11 times. Conditional
breakpoints are a good solution to this, but you need much more time
to set them up then a non-conditional breakpoint which would do the
same thing, if it was present.
Since you want to guarantee at least one iteration for the "b" loop, couldn't
a better idiom be the do ... while() loop?
The example I gave is not an example of what I want to do, but the
example on which Eclipse fails to allow me do what I want to do. Yes,
for the above examples your code transformation is correct - that
wasn't the point, though.
To restrict the scope of the booleans you could use for ( ... ).

void test()
{
for ( boolean a = true; a; )
{
a = ! otherMethodReturningBoolean();
doOtherStuff();

for ( boolean b = true; b; )
{
b = ! yetAnotherMethodReturningBoolean();
doStillOtherStuff();
}
}

}

Now your breakpoints are on the "for" lines.
Agree with this. Again, the above were only the examples to explain
the problem and this also poses another problem with all the solutions
- I am not in the position to change all the code I debug. It's team
play. I need a debugger that can debug any code, not requiring me to
change it to allow debugging. If the only problem was to allow
debugging, adding simple "int nop1 = 0;", "int nop2 = 0;" and so on
just after the while loops end would allow me to do what I want.
Briefly put - it's possible, but it's a pain to do it that way.

I respect your opinion, but it still sucks. I still think this is like
using a hand crank to start the car in the era where keys are normal
thing. What would you say if I told you something like this: hey, on
our new XYZ car model MMNN you really cannot use the ABS system
everywhere, only where "there is a place to stop". Why? OK, I agree
that adding code (nops) is bad, but a) I am not sure NetBeans does it
and still allows this (albeit partially) and b) even if that is the
only way to do it, let's make a switch to compile the code with nops.

I am asking too much from free software and I should not complain this
much at least because of that reason. As I said, let's cut to the real
work and leave the philosophy to someone with more respect to how the
things really are. Again, sorry if I offended anyone - I'll retreat
now.

In fact, let me add one more thing. When I look it from another
perspective, it doesn't suck that much. I cannot say it sucks that
much, because someone else might just come and say "well, I
desperately need this ABC thing in Eclipse and it's not there". Well,
dude, it ain't there, so shut up and work with what is there. People
did a great job building Eclipse, it works marvelously, it has 100s of
features - what else do you want?! It sucks for me only, because I
needed this feature. I still would like it to be a part of Eclipse.
Guess I just wanted too much.
 
D

dt

There IS something at the closing brace of a method that can complete
normally. The JVM does not magically intuit the need to pop a stack
frame and jump to the caller's code. It executes a return instruction.
I suspected so, but I really don't know how JVM works.
The fact that Eclipse does implement break on method exit proves that it
can do so. The issue is not one of executable program structure or
virtual machine capability, but of user interface.
Although this is probably not true for the end of the while loops. As
far as I recall, they are implemented something as:

1. condition check
2. if failed jump to the first instruction after the body of the loop
(i.e. 5)
3. body of the loop
4. jump to beginning of the loop (i.e. 1)
5. first instruction after the body of the loop

Again, I don't know if this is true for JVM. If, however, true, this
would probably involve adding some code if implemented for all loop
levels (i.e. with possibility to stop on fall through any of the
loops). Although, as I said, this is probably not implemented in other
IDEs.
 
L

Lew

I suspected so, but I really don't know how JVM works.

NetBeans honors end-of-method breakpoints with just a click in the margin, but
not end-of-block breakpoints. I marked with comments where I set breakpoints
in NetBeans 5.5.1, "honored" if the debugger stopped on it, "not" if it didn't.

<scce>
public class TestBreaks
{
public void breakpointTest() // based on dt's example
{
int a = 0;
while ( a < 100 )
{
a++;
if ( a == 11 )
{
break; // honored
} // not
} // not
} // honored

public static void main( String [] args )
{
new TestBreaks().breakpointTest();
} // honored

}
</scce>

I am curious to find out how NetBeans 6.0 handles breakpoints. It's out in
"preview" and it uses the built-in javac hooks in Java 6,

<http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/beta2.html>
item 6, re <http://jcp.org/en/jsr/detail?id=199>,

and the enhanced pluggable annotation processing feature,

ibid., item 7, re <http://jcp.org/en/jsr/detail?id=269>.
 
L

Lew

Lew said:
I am curious to find out how NetBeans 6.0 handles breakpoints. It's out
in "preview" and it uses the built-in javac hooks in Java 6,

Unfortunately, NetBeans 6, preview, does not install on my system. The
installer just barfs some message about an so being the wrong ELF type. Back
to the drawing board with you, NetBeans folks. (Why should a Java program
need an so? Maybe the installer isn't a Java program.)

Oh, well, the 5.5 behavior is sufficient to my needs. I feel sorry for the OP
that Eclipse sucks so bad for them.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top