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.

Bug 57748

Summary: Get rid of the need to handle UserQuestionException
Product: platform Reporter: Jesse Glick <jglick>
Component: Data SystemsAssignee: 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
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.
Comment 1 Martin Entlicher 2005-04-12 16:05:49 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....
Comment 2 Jesse Glick 2005-04-12 17:57:04 UTC
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?
Comment 3 Jesse Glick 2005-04-12 19:02:46 UTC
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.
Comment 4 Jesse Glick 2005-04-12 19:08:49 UTC
...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?)
Comment 5 Jesse Glick 2005-04-12 21:26:19 UTC
...and see for example issue #57794, another complication.
Comment 6 Jesse Glick 2005-12-07 15:22:29 UTC
Another one.
Comment 7 Quality Engineering 2009-12-21 07:26:24 UTC
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
Comment 8 Jesse Glick 2010-03-16 00:55:11 UTC
I think this is still valid; we have an unusable API that could perhaps be replaced.
Comment 9 Ondrej Vrabec 2010-03-19 14:27:49 UTC
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?
Comment 10 Jesse Glick 2010-03-19 20:55:47 UTC
(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.
Comment 11 Jesse Glick 2010-09-23 19:58:44 UTC
Do you plan to work on this? Would be API_REVIEW_FAST I think.
Comment 12 Tomas Stupka 2010-09-24 10:22:09 UTC
> 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
Comment 13 Jesse Glick 2010-09-24 17:12:46 UTC
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.
Comment 14 Jaroslav Tulach 2010-09-29 17:32:24 UTC
Thrown only from DataEditorSupport? Then won'tfix.
Comment 15 Jesse Glick 2010-09-29 22:19:19 UTC
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.
Comment 16 Jesse Glick 2010-10-15 20:32:28 UTC
Not an immediate priority however.
Comment 17 Jaroslav Tulach 2012-11-07 16:36:33 UTC
I'd like to remove the burden of dealing with UQE from callers and rather modify an infrastructure to deal with it automatically.
Comment 18 Jaroslav Tulach 2012-11-07 16:37:35 UTC
Created attachment 127332 [details]
A dialog is shown when UQE is thrown and reported
Comment 19 Jaroslav Tulach 2012-11-07 16:38:21 UTC
The o.n.bootstrap/src/org/netbeans/ModuleManager.java part of the patch is unrelated.
Comment 20 Jaroslav Tulach 2012-11-13 08:35:47 UTC
About to integrate tomorrow.
Comment 21 Jaroslav Tulach 2012-11-14 13:57:26 UTC
ergonomics#16bd4d64f3f1
Comment 22 Quality Engineering 2012-11-21 13:41:31 UTC
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