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

Bug 1729

Summary: HCR with compilation error (1GKF820)
Product: [Eclipse Project] JDT Reporter: Darin Wright <darin.eclipse>
Component: DebugAssignee: Jared Burns <jared_burns>
Status: RESOLVED WONTFIX QA Contact:
Severity: minor    
Priority: P1    
Version: 2.0   
Target Milestone: 2.0 M3   
Hardware: All   
OS: All   
Whiteboard:

Description Darin Wright CLA 2001-10-10 22:18:20 EDT 
DW (9/21/2001 3:52:58 PM)
	Drop to frame occurrs even though a type was not reloaded.

	Using J9.

	1) Set a breakpoint in "DropTests", on the "System.println..." method (in method4())
	2) Debug, and when the breakpoint is hit remove the closing quote from the
		println, introducing a syntax error.
	3) Save
	4) The syntax error appears, and the debugger performs a drop to frame even though
	there are compilation errors in the type and it was not reloaded.

DW (9/21/2001 3:56:34 PM)
	If a CU has compilation errors, we should not attempt a re-load. Or, we should only
	drop those frames for which re-load was successful.
Comment 1 Jared Burns CLA 2002-02-04 09:09:12 EST 
This is not always true.

For example, it's entirely possible for someone to load a program that has
compilation errors, debug to the errors, and then fix them as they go. Thus, the
user *would* want to reload a class with errors - in this case, because the new
class would have *less* errors than the original.
I think this behavior will have to be user-controlled. That is, it will need a
callback mechanism to the UI to prompt the user ("You have compilation units
with errors. Do you want to load these new classes in the VM?").
Comment 2 Darin Wright CLA 2002-02-26 11:32:44 EST 
Leave as is. We run/debug with compilation errors.