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.
It would be much better if UserQuestionException were deprecated (and not thrown from vcscore), specifically in FileObject.lock(): any code calling this method is supposed to catch UQE and deal with it somehow, yet most client code does not actually do this, since 1. It is often tricky to write the handler correctly - you must reacquire locks, deal with several failure scenarios, etc. 2. Unit testing such code is not easy either. You would have to have a fake FileSystem that throws UQE at certain times. 3. Manually testing this code is not easy. You need a certain kind of VCS set up, like PVCS. 4. This code path is not commonly encountered in practice, so it gets little field testing. Since it costs a lot in developer and QA time to use this API, it would be much preferable to handle things differently, so that all the logic surrounding VCS edit locks is encapsulated in the VCS modules, and other clients don't have to worry about it. Possibilities include 1. Either always call EDIT immediately (without prompting), or never call EDIT automatically, at the user's option. Simple and effective, but may be annoying for regular users of pessimistic locks. 2. Let FO.lock() succeed even if the file is not locked by the user; if FO.gOS(lock) is called, store the written content for file in some .#file (or similar), and when OS.close() is called, asynchronously prompt the user to EDIT the file - if accepted, move .#file to file, else discard .#file. Make FO.getInputStream, .lastModified, .size, etc. work on .#file if it exists, to simulate having actually written the file. Possibly nicer for users, but could cause problems for modules which expect the java.io.File to have been modified as soon as the FO's outputStream was closed.
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