| Summary: | [ltk] Improve error reporting when deleting a project fails | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | daniel_megert, helmut.haigermoser, markus.kell.r, ob1.eclipse, Szymon.Brandys | ||||||||
| Version: | 3.6 | ||||||||||
| Target Milestone: | 3.8 M7 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Martin Oberhuber
Created attachment 200213 [details]
screen shot of the error dialog
@ll, I've attached the error dialog showing up in such cases. Can someone from the platform team comment on this, I'm thinking the wording could easily be changed, the term "refactoring" is really misleading since the customer did a "remove project", so the error should be changed to saying: Error removing the project "name", would you like to: - Undo or - Cancel the operation? Note that undoing a deletion is tricky, have we stored the files somewhere so we can recover? I'd guess no, so the dialog might best be changed to a "Cancel" button, with some good advice on how to best recover: - check for file locks of your project - check for <whatever> - reboot in cases you can't find out - delete the project again Helmut It would be nice to point at hints in such a case. I think that a link to the help would be good enough here. (In reply to comment #3) > It would be nice to point at hints in such a case. I think that a link to the > help would be good enough here. Yes, this definitely is more of a documentation change we need, but I would also suggest to try and get the term "refactoring" eliminated from the message since this information, refactoring has failed, is an implementation detail leaking into the customers hands, and he does not know how to deal with that... Better to state: Deletion has gone wrong, some file on the disk cannot be removed, cancelling our of here, please correct the condition and retry... Helmut The dialog is org.eclipse.ltk.internal.ui.refactoring.ChangeExceptionHandler. Note also that "Undo" button on the dialog is misleading as deleted entries are not restored. I agree we can do better here (improve dialog title and message). (In reply to comment #6) > I agree we can do better here (improve dialog title and message). Thanks Dani :) So, can we get this change on the way for 3.8? What changes are possible though, this being part of the refactoring framework Helmut Ping, any ideas how to proceed on this ? The issue is really annoying related to external (Makefile) builds ... since it can can happen that the build process spawns a Job from its current directory, which then "locks" the current directory on Windows. Trying to delete a project after having performed a build can then fail with this very unobvious error messages. I'd really like to see some improvement here. Created attachment 210495 [details]
Better?
Created attachment 210496 [details]
Possible fix
Markus, please review. I'm not sure whether replacing the general title with the name of the change works for all our refactorings.
Also, ignoring the 'NullChange' undo needs a review.
(In reply to comment #9) > Created attachment 210495 [details] > Better? good! :) Helmut The patch was OK for the given scenario, but we better don't create the bad NullChange at all. Result for this bug is still attachment 210495 [details]. Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a5032a72fa1ab61dcfede1919f858f1c8b58b603 (In reply to comment #12) > The patch was OK for the given scenario, but we better don't create the bad > NullChange at all. Result for this bug is still attachment 210495 [details]. > > Fixed with > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a5032a72fa1ab61dcfede1919f858f1c8b58b603 Looks good to me. Thanks Markus. |