Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 6400

Summary: DCR - suggestion to improve running vs. debugging
Product: [Eclipse Project] JDT Reporter: Steve Northover <snorthov>
Component: DebugAssignee: Darin Wright <darin.eclipse>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: cocoakevin, erich_gamma
Version: 2.0   
Target Milestone: 3.0 M8   
Hardware: Other   
OS: other   
Whiteboard:

Description Steve Northover CLA 2001-11-28 16:59:18 EST
The classic error is to press the run button instead of the
debug button and waste time wondering where the debugger is.
A simple fix would be to always run the debugger when any
break point is set anywhere in Eclipse.  Of course, this should
be configurable.
Comment 1 Erich Gamma CLA 2001-11-29 06:07:29 EST
We have looked into this. The problem is that users almost always have a 
breakpoint set in the workspace from the last debugging session. Breakpoints 
are "global" in the sense that we can't know which breakpoints are effective 
for a particular run. This means the user will almost run under the debugger. 
Since it is slower than normal running I'm concerned about even providing this 
as an option. 

Moving to Debug for further comments
Comment 2 Steve Northover CLA 2001-11-29 11:46:56 EST
So make it an option that people can turn off.  You could also
get rid of both buttons, only have one and prompt - "You have
enabled break points, do you want to debug?".  Again, all of
this should be optional.

Coming from VA/Java to LF and Eclipse, this particular thing
still burns me, even after all this time.  Given that things
are less interactive in the JDK (no hot code replace) it often
takes a long time to get to the state you care about and it
drives you nuts to find out later that you were running.

Can we also optimize debug so it matters less?  Given that we
are running in an IDE, if debug took the same time as run, I
think we'd always want to debug.
Comment 3 Darin Wright CLA 2002-02-26 15:26:25 EST
Another possilbe solution would be to allow actions from action sets to be 
added selectively (i.e. select actions within actions sets). Users who do not 
want the run button could throw it away.
Comment 4 Steve Northover CLA 2002-02-26 19:15:55 EST
I don't want to get rid of the run button, I just want the right thing to 
happen.  I don't buy EG's argument.  Yes users will "run the debugger" when 
they have a break point set but they will get a prompt "Did you mean to debug?  
I see you have breakpoints set ...".  The dialog can have a "never ask me 
again" option and the whole thing could be configured so that users can have 
the old behavior back again.

When I entered this PR, I was used to V/A Java.  These days I care less but 
it's still annoying.  Think about it, when do you ever set a break point and 
then mean to run a program instead of debug?  It's one of the small things that 
we could do that would make sense and make the IDE better.  The real problem is 
that you "run" and then find out lots later that you meant to "debug" because 
there is no strong visual cue that this is what you just did.
Comment 5 Darin Wright CLA 2002-02-27 08:40:34 EST
I actually do quite often have breakpoints set, and use "run" mode. I often 
leave breakpoints lying around to re-use on future debug sessions. I dialog 
would not kill me, but at this point, it would be a surprise to many users (so 
perhaps a better default would be to have the dialog turned off, and let those 
who want it, turn it on). I think the key observation is that this is a problem 
for people who are (recently) switching from VAJ - however, once you are used 
to the idea, it's not that difficult. (Note that VAME has two buttons as well).
Comment 6 Steve Northover CLA 2002-02-27 10:45:18 EST
Agree that VAME users have less of a problem.  I still think that this is a 
fundamental problem in our product and that we should do something about it so 
for me, the issue is not RESOLVED.  I also care less these days about it.
Comment 7 Steve Northover CLA 2002-09-10 10:14:52 EDT
I still think this is wrong and do it all the time.  So does everyone on my 
team.  However, I don't actually expect you to fix it.
Comment 8 Darin Wright CLA 2003-05-12 14:38:03 EDT
Re-opening to close. We do not intend to change the current 
implementation/behavior. We are actually adding providing support for an 
extensible set of launch modes (for example, "profile").
Comment 9 Darin Wright CLA 2003-05-12 14:38:20 EDT
Marking as "won't fix".
Comment 10 Steve Northover CLA 2003-05-12 18:09:34 EDT
Interesting.  As long as the solution solves the problem that 99% of the time 
when I set a breakpoint I mean to debug despite the fact that I pressed run.  

If this problem isn't solved by "launch modes", then you really aren't solving 
my problem at all, just closing the PR and saying WONTFIX (condeming me and 
others like me to the endless torment of run vs. debug).  Not sure why adding 
a dialog "Did you mean to debug?" with the check option "Never ask me again" 
is such a bad idea?
Comment 11 Darin Wright CLA 2003-05-13 09:42:47 EDT
I am simply trying to torment you :-)

Launch modes does not address your issue. It means that we are adding another 
launch button - which makes your problem worse. The bug is marked as "won't 
fix" since we have no intention of adding prompters when you press one of the 
launch buttons. It seems to me there are too many questions:

* (no breakpoints, press debug or profile) "Did you really mean to run?"
* (breakpoints, press run or profile) "Did you really mean to debug?"
* (none or some breakpoints) "Or perhaps you meant to profile your application?"

Thus far, we have seen no complaints (outside of this bug report) that this is 
a serious usability issue (Votes = 0).
Comment 12 Steve Northover CLA 2003-05-13 13:32:36 EDT
The answers to these questions are obvious:

* (no breakpoints, press debug or profile) "Did you really mean to run?"
* (breakpoints, press run or profile) "Did you really mean to debug?"
* (none or some breakpoints) "Or perhaps you meant to profile your 
application?"

(no breakpoints, press debug or profile) -> do it
(breakpoints, press run or profile) -> prompt
(non or some breakpoints) -> do it

The only case where you get caught is when you set a breakpoint and press run, 
get 60,000 miles into the problem, setting the initial state, answering all 
the right questions only to find out that you are running!

It's an old complaint and easy to fix and also easy enough to get rid of for 
those that don't like it ("never prompt me").  Do you think it's worth my time 
trying to drum up support from the community?
Comment 13 Steve Northover CLA 2004-01-06 14:31:20 EST
Too bad, yet again about this one.  I notice we now have a dialog that says 
something like "Workspace is building, do you want me to wait?".

Do you realize how much time this one simple change would save Eclipse users?
Comment 14 Steve Northover CLA 2004-02-16 16:05:25 EST
NOTE:  I saw Erich make exactly the same mistake during his demo at 
EclipseCon.  Why is this so hard to change given that we are already prompting 
when the workspace is building?  This one simple feature would save the 
Eclipse community hours of wasted time.
Comment 15 Darin Wright CLA 2004-03-16 13:34:44 EST
Re-open to address with bug 45887 and bug 54925.
Comment 16 Kevin Barnes CLA 2004-03-18 13:21:48 EST
patches submitted for this bug along with bug #45887 and bug #54925. (patches 
attached to #45887).
Darin, please verify
Comment 17 Steve Northover CLA 2004-03-18 13:47:47 EST
This isn't actually getting fixed, is it?  Yes! Yes! Yes!
Comment 18 Darin Wright CLA 2004-03-18 15:23:35 EST
Applied patch. I think we should promte this to function in the debug 
platform, rather than making it Java specific. Please move prompt & preference 
to the debug platfrom.
Comment 19 Darin Wright CLA 2004-03-19 14:45:57 EST
This is now fixed. Support exist in the debug platform, but launchers have to 
subclass our abstract launch delegate to inherit the feature. Currently, Local 
Java Apps, Applets, and JUnit launch config types have the behavior. Logging a 
bug against PDE to subclass our new launch delegate.
Comment 20 Darin Wright CLA 2004-03-19 14:46:13 EST
Verified.
Comment 21 Steve Northover CLA 2004-03-26 12:39:38 EST
If the breakpoints are not active, the dialog shouldn't be launched.
Comment 22 Steve Northover CLA 2004-04-02 10:30:48 EST
The dialog should allow you to cancel the operation (running nothing) so you 
can go and clear the breakpoints.  Also, it needs to have the standard check 
box "don't ask me again" button that other dialogs of this type have.
Comment 23 Kevin Barnes CLA 2004-04-02 12:08:26 EST
reopening for consideration of comment 21 and comment 22
Comment 24 Steve Northover CLA 2004-04-02 12:20:26 EST
There are a bunch of places where this new kind of dialog has appeared.  It 
needs to have the "Eclipse standard" look for dialogs of this type or it will 
piss too many people off.
Comment 25 Kevin Barnes CLA 2004-04-02 12:38:11 EST
I agree. Reported new Bug# 57272 to handle the problem with the dialog.
Comment 26 Kevin Barnes CLA 2004-04-05 12:43:36 EDT
Only show dialog if the BreakpointManager is enabled and there is at least one 
enabled breakpoint in the workspace.

fix in LaunchConfigurationDelegate and LaunchConfigurationMessages.properties
Comment 27 Kevin Barnes CLA 2004-04-05 12:43:55 EDT
Darin, please verify
Comment 28 Darin Wright CLA 2004-04-05 16:01:21 EDT
Verified.
Comment 29 Steve Northover CLA 2004-05-14 19:38:21 EDT
Does it make sense to add an option to disable break points from within the 
dialog?  That way you can run right away and keep the warning dialog active 
for the future without having to exit, disable or remove break points.  
Otherwise its tempting to say "never show me again" (or whatever) rather than 
going and removing break points.  The issue here is that you are hot to see 
your code run and quitting, fixing the break points state and running again is 
a pain.