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.
Build 200302110100 Linux RH 7.2 JDK 1.4.1 Steps to reproduce: I have 2 java files in one package. I want to rename one to other's name (removing). It only throws FSException and files stay as before.
Created attachment 8895 [details] FSException's stack trace.
Hmm, there should be some informational exception thrown , that file already esists. IMHO: your attached exception is only annotation, IllegalArgumentException arises ( so maybe only detect why it is impossible to copy file - and inform user about purpose - I am not sure it is possible to implement this detection )
I think there should invokes some YES/NO type dialog with question if a user wants to overwrite (replace) existing file. Good file management is a base of user contentment.:)
I think, that YES|NO dialog isn't necessary. But the exception must be correctly annotated. I think that better and faster editor is for IDE mere important than confirmation dialog "target file allready exists<Oweride> <cancel>, isn't it.
I don't consider this issue as a bug. Behaviour is OK and exception is corectly annotated. java.io.File.rename returns true or false if rename succeeds or not. There is no additional information. I don't think there is necessary to do additional check and try to predict cause.
incorrect annotation of exception.
build [200302200100]
Created attachment 9060 [details] exception stacktrace
Hm, there is maybe problem in error manager. The exception is annotated correctly as WARNIGN. But in ErrorManager is probably incorrectly notified. David, can you evaluate this exception?
If the annotation is of type warning the correct dialog should pop up (if the notification is standard). The problem can be in ErrorManager or in the call to ErrorManager while notifying it.
Created attachment 9167 [details] A proposed hot fix.
I am sorry I have attached the patch to the wrong issue.
David, the exception is annotated as USER. I wrOte small test: ErrorManager em = ErrorManager.getDefault(); Exception e = new Exception (" ....."); em.notify(ErrorManager.USER, e); It shows notify exception dialog.
Jesse, it seems that notifying in ErrorManager is seriously broken. If you have an exception annotated with say warning severity and call regular notify(e) the severity is EXCEPTION. It breaks code on several places. Also please check Petr's example. Could you please evaluate?
Yes, I know. Severity of nested annotations is actually ignored. The only important thing is the severity you notify with. Unfortunate, but (1) it has been this way forever IIRC and changing it now would probably break other stuff; (2) the API design is very muddled and does not really provide a clear solution. There are multiple places where a severity may be set, and there is no rule I can think of for composing them logically. I don't like it at all but I have thought about it before and can't think of any safe way to solve it besides an incompatible rewrite of the ErrorManager API. So, the code calling notify needs to decide on an appropriate severity. It can either hardcode this - e.g. USER in this case - or do some sort of heuristic search through nested annotations and try to retrieve some severity from them. Frankly I have no idea what the desired behavior is in general.
Back to you again ...
Apparently EM.notify(Throwable) with no explicit severity needs to run code which automatically extracts a severity from annotations.
*** Issue 31254 has been marked as a duplicate of this issue. ***
Probably can be treated as P2.
Have patch which works on unit test anyway. To Petr: ErrorManager em = ErrorManager.getDefault(); Exception e = new Exception (" ....."); em.notify(ErrorManager.USER, e); This code *should* show an exception dialog. You need a localized annotation for it to display nicely.
Interestingly RenameAction & TreeViewCellEditor do not use exactly the same algorithm for determining when to add localized annotations; or specifically, one notifies with USER severity and the other with unspecified severity. So they will behave a bit differently (different dialog icons) for the original test case but otherwise be OK.
Prep work: committed * Up-To-Date 1.7 ant/src/org/apache/tools/ant/module/api/DefinitionRegistry.java committed * Up-To-Date 1.14 ant/src/org/apache/tools/ant/module/api/IntrospectedInfo.java committed * Up-To-Date 1.16 ant/src/org/apache/tools/ant/module/run/OutputWriterOutputStream.java committed * Up-To-Date 1.3 core/javahelp/src/org/netbeans/modules/javahelp/AbstractHelp.java committed * Up-To-Date 1.8 core/javahelp/src/org/netbeans/modules/javahelp/HelpAction.java committed * Up-To-Date 1.17 core/src/org/netbeans/core/modules/Events.java committed * Up-To-Date 1.48 core/src/org/netbeans/core/modules/Module.java committed * Up-To-Date 1.47 core/src/org/netbeans/core/modules/ModuleList.java committed * Up-To-Date 1.57 core/src/org/netbeans/core/modules/ModuleManager.java committed * Up-To-Date 1.4 cpp/src/org/netbeans/modules/cpp/builds/OutputWindowOutputStream.java committed * Up-To-Date 1.2 logger/tests/mod16/Mod16Main.java committed * Up-To-Date 1.27 openide/src/org/openide/actions/MoveUpAction.java committed * Up-To-Date 1.33 openide/src/org/openide/util/HelpCtx.java committed * Up-To-Date 1.2 testtools/src/org/netbeans/modules/testtools/OutputWriterOutputStream.java committed * Up-To-Date 1.6 tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/Tomcat5DO.java committed * Up-To-Date 1.4 tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/Tomcat5WebServer.java committed * Up-To-Date 1.13 web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JspSyntaxSupport.java
Then fix itself: committed * Up-To-Date 1.50 core/src/org/netbeans/core/NbErrorManager.java committed * Up-To-Date 1.3 core/test/unit/src/org/netbeans/core/NbErrorManagerTest.java committed * Up-To-Date 1.26 openide/src/org/openide/ErrorManager.java
Merged a much simplified version that does not fix everything that the trunk version fixed, just fixes the regression introduced by the fix for issue #28990. It at least does work as desired for the case of the attempted renaming of a Java file in a package to an existing name - only a polite message is displayed. Trunk version also: - gets rid of usage of UNKNOWN for logging, reserving it only for notification - implements searching for severities in nested annotations as well as the main one (helpful for rethrowing) - makes some fixes in handling of localized annotations, especially nested ones - includes an expanded test case committed * Up-To-Date 1.49.2.1 core/src/org/netbeans/core/NbErrorManager.java committed * Up-To-Date 1.25.2.1 openide/src/org/openide/ErrorManager.java
Verified. The exception annotations are correctly shown in 200303120350.
Maybe I've misunderstood, but in the 3.5 branch, NullPointerException npe = new NullPointerException("test"); err.annotate(npe, ErrorManager.EXCEPTION, "foo", "bar", new Exception(), new Date()); err.notify(npe); doesn't notify. I'd have thought it should, since err.isNotifiable(ErrorManager.EXCEPTION) == true.
What doesn't notify? I am unaware of any problem. In r35 branch, I run with internal execution: import java.util.Date; import org.openide.ErrorManager; public class Foo { public static void main(String[] args) { ErrorManager err = ErrorManager.getDefault(); NullPointerException npe = new NullPointerException("test"); err.annotate(npe, ErrorManager.EXCEPTION, "foo", "bar", new Exception(), new Date()); err.notify(npe); } } and an exception dialog appears saying "bar" with a stack trace available showing the main and nested exception. If you think there is some other problem somewhere, please file it separately with complete details to reproduce.
Oh dear. Jesse is (of course) right; I was wrong. I tried this in a fresh build of the IDE and it worked perfectly. I must have had a corrupt/out-of-date build before. Sorry for the false alarm.
Reopening. I think that this issue still persist (at least my original issue 31254 is still reproducible) in S1S 030408.
Keeping it open in issue #31254 instead, for tracking purposes.
Verified.