This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Get rid of the need to handle UserQuestionException | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jesse Glick <jglick> |
| Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | apireviews, jtulach, mentlicher, tmysik |
| Priority: | P3 | Keywords: | API_REVIEW_FAST |
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 46089, 57480, 57794, 67465, 190424 | ||
| Attachments: | A dialog is shown when UQE is thrown and reported | ||
|
Description
Jesse Glick
2005-04-11 20:34:24 UTC
Scheduling for 4.2 for now, even though it's not yet clear whether it's doable. Option 1) is possible even now (there is an option for that). So we can solve it by simply now allowing to set the interactive mode. Option 2) looks dangerous to me. But if properly implemented it should work. I'm only afraid about the discard of .#file when EDIT fails. One can write a long piece of code and it can get discarded. Throwing UQE in lock() is much more clear solution IMHO (the user can not write code unless we're sure that we can save the changes). We would have to leave the .#file there until the original file becomes writable. But then it will cause problems in compilation, etc.... Hey, idea for #2 that just might work: if EDIT fails (or user declines to try), discard .#file, but also fire an "external" FileChangeEvent on file! This would simulate (for the API client) having actually written the new content but then having it be reverted. (Compare this to the trick we do in the editor window when you try to type in a r/o buffer: the insert event is reverted.) Most API clients which really care about writing the file will (or should) already be listening for external file changes, anyway. For example, DataEditorSupport will reload the file, and project infrastructure will (in some cases) reload settings. Not sure if this works, though - depends on handling of FO.lock() vs. FO.getOS(lock). Might be subtle problems. For example, with DES, maybe FO.lock() succeeds, then user declines to EDIT (or EDIT fails), then user makes edits and tries to save - what happens? (Hopefully user is not that dumb, but someone will try.) There is no API for rejecting a FileLock retroactively. Yes of course compilation (or anything else requiring external tools) will not work until the real file has been written, but hopefully there won't be time for the user to *try* to do anything like Build Project before the dialog appears asking to take out an edit lock on the modified file. Option #3 (perhaps): if call to FO.lock() occurs in EQ, prompt to call EDIT synchronously - showing a modal dialog will just create a nested EventQueue, and the dialog probably does not need to acquire any new locks, so it should be safe. I'm not really sure what happens if you try to use SwingUtilities.invokeAndWait when the call to FO.lock() comes from some other thread. What was the original problem that UQE solves, anyway? BTW you probably already guessed that I am thinking of issue #57480 and issue #46089. :-) If you're just dealing with a single-file editor support, it's not so bad (and is thankfully solved in just one place in openide), but with projects it gets nastier... what if the user agrees to lock and modify project.xml, but not project.properties or build-impl.xml? There is no way to handle that very gracefully. Basically you have to implement your own atomic transactions or something like that. ...and re. #4, look at e.g. form/src/org/netbeans/modules/form/GandalfPersistenceManager.java. Does it handle UQE from the .form file? Doesn't look like it. Did anyone notice yet? Not according to Issuezilla. (Who wants to file it?) ...and see for example issue #57794, another complication. Another one. This bug was reported against NetBeans IDE 6.0 or an older release, or against a non-maintained module. NetBeans team does not have enough resources to get to this issue, therefore we are closing the issue as a WONTFIX. If you are interested in providing a patch for this bug, please see our NetFIX guidelines for how to proceed. We apologize for any inconvenience. Thank you. The NetBeans Team I think this is still valid; we have an unusable API that could perhaps be replaced. huh? jesse, you reopened the issue and reassigned from vcsgenerics to versioning/code, however i believe we don't use UserQuestionException anywhere in the versioning API. Are you sure it does not apply just to the old (and unsupported?) vcsgenerics code? (In reply to comment #9) > Are you sure it does not apply just to the old (and unsupported?) vcsgenerics > code? You would know better than I. If that is the case, then this needs to stay open until UserQuestionException is deprecated, and code catching (such as in project.ant) it is deleted. Do you plan to work on this? Would be API_REVIEW_FAST I think. > Do you plan to work on this? Would be API_REVIEW_FAST I think
no. just reassigned to owner. VCS code has nothing to do with UserQuestionException
Seems to only be thrown from DataEditorSupport (for >1Mb files). Many places currently catching it could probably stop doing so, assuming they are unlikely to be opening very large text files. Many impls seem to be wrong anyway - do not check return value of confirmed(). Rarely tested code paths are unlikely to be correct. Much better IMHO would be if the editor support went ahead and opened the large file, but only loaded the first 1Mb into memory, and marked the document provisionally read-only; there could be some UI in the editor window to load the full document writably. This would be better for users - they can always see at least the top of the file - and better for API clients - no need to deal with UQE. Thrown only from DataEditorSupport? Then won'tfix. Not sure what the last comment meant. There is an ongoing maintenance problem in all the places where code has to catch UQE and somehow respond. Most of this code was written to support SCMs with mandatory locks; it could be made simpler and more reliable if the one remaining use for UQE - opening very large files - were implemented differently. Not an immediate priority however. I'd like to remove the burden of dealing with UQE from callers and rather modify an infrastructure to deal with it automatically. Created attachment 127332 [details]
A dialog is shown when UQE is thrown and reported
The o.n.bootstrap/src/org/netbeans/ModuleManager.java part of the patch is unrelated. About to integrate tomorrow. ergonomics#16bd4d64f3f1 Integrated into 'main-golden', will be available in build *201211211016* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/16bd4d64f3f1 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #57748: Exception displaying infrastructure understands UserQuestionException |