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.
See Jesse's mail: ------------------- We have persistent problems with issues such as http://qa.netbeans.org/issues/show_bug.cgi?id=151498 which involve an exception being thrown from the same piece of code but for different reasons each time. Often this is an IAE or ISE; the code throwing the exception is behaving as designed, it is some caller higher up in the call stack which is doing something wrong. If the caller is pretty close to the thrower, then the exception reporter's stack trace similarity algorithm decides that two stack traces from different callers are indeed distinct, and files separate issues for them - which is good, since they get tracked independently and reopened only if they really should be. But if the caller is deeper in the stack trace, all the stack traces look the same for the first few lines and get grouped together. Then we go into the exercise of trying to pick out which ones belong to whom, reassigning the issue to different people at different times, the issue gets reopened assigned to person #13 when the problem is really a distinct issue that should be assigned to person #14, some less usual stack traces get ignored, etc. - a mess. Tuning the similarity algorithm to require more lines of similarity would help this problem, but would result in too many unclassified duplicates from cases where the immediate code really is at fault - e.g. an NPE - just being called in slightly different, and insignificant, ways. Can the throwing code somehow "hint" the stack trace so that the server knows which parts of the lower stack trace are expected to be common to all occurrences? For example, in the issue I mentioned, perhaps the throwing code can be amended to read something like this: throw new IllegalStateException("Should not acquire Children.MUTEX while holding ProjectManager.mutex()\n[EXCUSE org.openide.util.Mutex org.openide.nodes.*]"); The specially formatted line in the message would let the server know that before applying its usual algorithm, it should first trim off any lines from the bottom of the stack trace (i.e. first lines when printed) matching those patterns. Then it would get a collection of traces which either look like java.lang.IllegalStateException: Should not acquire Children.MUTEX while holding ProjectManager.mutex() [TRIMMED] at org.netbeans.modules.cnd.makeproject.ui.MakeLogicalViewProvider$BaseMakeViewChildren.stateChanged (MakeLogicalViewProvider.java:1489) at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.fireChangeEvent(Folder.java:910) at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.fireChangeEvent(Folder.java:899) at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.addElement(Folder.java:410) [...] or java.lang.IllegalStateException: Should not acquire Children.MUTEX while holding ProjectManager.mutex() [TRIMMED] at org.netbeans.spi.java.project.support.ui.PackageViewChildren.refreshKeys(PackageViewChildren.java:244) at org.netbeans.spi.java.project.support.ui.PackageViewChildren.fileFolderCreated(PackageViewChildren.java:396) at sun.reflect.GeneratedMethodAccessor60.invoke(GeneratedMethodAccessor60.java:0) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [...] -------------------
A method call to associate hints with the exception would also be fine; say, something like IllegalStateException x = new IllegalStateException("Should not acquire Children.MUTEX while holding ProjectManager.mutex()"); Exceptions.ignoreProximateCallers(x, "org.openide.util.Mutex", "org.openide.nodes.*"); throw x; I'm not sure what the hypothetical ignoreProximateCallers method would do; perhaps work similarly to attachMessage but with a different kind of LogRecord, one which TopLogging would probably suppress but which the exception reporter would send in a special field to the server.
test