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.
I wouldn't think an API should ever throw assertion. Is NB expected to behave if assertions are disabled? Acc'd to javadoc for "Error", superclass of AssertionError, > serious problems that a reasonable application should not try to catch In module I work with, user command processing catches any "Exception" that might occur to do some cleanup. Seems like this situation, doc already locked, a RuntimeException, eg IllegalStateException, > not in an appropriate state for the requested operation might be more appropriate. (the assertion is preferable to a deadlock :)) java.lang.AssertionError: JavaSource.runCompileControlTask called under Document write lock. at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:512) at org.netbeans.modules.java.source.save.Reformatter$Lock.lock(Reformatter.java:439) at org.netbeans.modules.editor.indent.TaskHandler$MimeItem.lock(TaskHandler.java:323) at org.netbeans.modules.editor.indent.TaskHandler.lock(TaskHandler.java:152) at org.netbeans.modules.editor.indent.IndentImpl.reformatLock(IndentImpl.java:132) at org.netbeans.modules.editor.indent.FormatterImpl.reformatLock(FormatterImpl.java:68) at org.netbeans.editor.Utilities.reformat(Utilities.java:914)
Yes, it should probably be ISE instead. BTW could you please attach the top of the stacktrace so that we know the originator of the reformat? Or is it called from jvi's code so you'll fix that?
Two parts here, IMO: 1. use of assertion to check preconditions of an API: I agree the API should check its preconditions regardless the assertions are enabled or not, but in some cases there is a reason to check the precondition only when assertions are enabled - if the check is (possibly) time-consuming, which is this case. So this should not be changed, IMO. 2. use of AssertionError instead of ISE: yes, ISE would probably be better, but I do not think this is very important. I am not sure if doing cleanup in catch section is a good idea. Maybe something like: boolean finished = false; try { doSomething(); finished = true; } finally { if (!finished) { //do the cleanup } }
Yes, called from jVi; my issue. (Difficult to fix without Issue 103467 since involves jVi's undo/redo handling and its use of atomicLock/breakAtomicLock) I see, EWouldBlock is an expensive check. BTW. Over the weekend I saw in source the following, which should be IllegalArgumentException, in editor/indent/src/org.netbeans.modules.editor.indent. Can I just mention that here rather than file another issue? IndentImpl.java:152: assert (startOffset <= endOffset) : "startOffset=" + startOffset + " > endOffset=" + endOffset; // NOI18N IndentImpl.java:216: assert (startOffset <= endOffset) : "startOffset=" + startOffset + " > endOffset=" + endOffset; // NOI18N
About using a finally rather than a catch. Why is using finally an improvement over catch?
Fixed asserts in editor/indent: Checking in IndentImpl.java; /cvs/editor/indent/src/org/netbeans/modules/editor/indent/IndentImpl.java,v <-- IndentImpl.java new revision: 1.10; previous revision: 1.9
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX