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.
[dev oct 30] Consider the following stack trace (how it happened is irrelevant): java.lang.IllegalArgumentException: Line index=-1 must be >= 0 at org.netbeans.editor.BaseDocument$LineRootElement.getElement(BaseDocument.java:1127) at org.openide.text.NbDocument.findLineOffset(NbDocument.java:116) at org.openide.text.DocumentLine$Set.getCurrent(DocumentLine.java:718) at org.netbeans.modules.apisupport.layers.LayerDataNode$LayerChildren$Hyperlink.<init>(LayerDataNode.java:371) [etc.] Line.Set.getCurrent is declared to throw IndexOutOfBoundsException if passed an illegal line number. In fact apisupport is here catching that exception and ignoring it safely. But NbDocument.findLineOffset which actually does the work is not declared to throw anything. Nor is javax.swing.text.Element.getElement. In fact the editor module implementation of it throws a different unchecked exception, which is not at all documented. I guess this is an API bug although I am not sure what should be done about it. Probably NbDocument.findLineOffset should be changed to explicitly say IOOBE may be thrown (this is technically incompatible but oh well), the editor module changed to throw it, and the Editor API edited to recommend that editors throw this exception from Element where appropriate.
Well, its complicated a bit. 1) javax.swing.text.Element doesn't declare which exception it throws, just emphasizes the argument should be >=0. The AbsractDocument.BranchElement implementation throws IOOBE exception in that case, but it doesn't describe it in javadoc. So I guess one part the BaseDocument.LineRootElement should also throw IOOBE instead of IAE. 2) NbDocument.findLineOffset doesn't declare the exception IOOBE to be thrown but it would be the good way I think. I looked at the code and seen there could even NPE to be thrown, there is not counted with the situation null line element is returned when too big line number is specified. This has to be handled the way IOOBE is thrown. In sum I would do it this way: 1) BaseDocument.LineRootElement to throw IOOBE instead of IAE 2) NbDocument.findLineOffset handle the possible null element and throw IOOBE in that case. 3) Probably the most problematic, is it possible to add to javadoc of NbDocument.findLineOffset it can throw IOOBE or leave it that way. Your opinion is needed first. Thanks.
IMHO: do 1. and 2. and add that to the Javadoc for 3. It should probably be mentioned in apichanges.xml in <compatibility> as incompatible but with the explanation: you should explicitly catch IOOBE from this method; formerly it was not documented to throw this but in fact did throw other undocumented (and less pleasant) exceptions, so code using findLineOffset directly is probably no worse off than it was, and code using it indirectly via Line.Set etc. will already be fine.
Now throwing IOOBE instead of IAE in BaseDocument to be compatible with Swing.
Fixed in [main-trunk]. Fix: openide/../openide/text/NbDocument.java [1.46]. Jesse, so the above is done. But I don't want to put the state its incompatible change. From NbDocument.findLineOffset could be thrown unchecked: Before: IOOBE if 'standard' swing doc was used. IAE if our editor's doc was used, what is fixed now, NPE if the index was bigger than amount of lines. (Of course also other ugly thing could happen but we are interested just for the above cases). Now: For all above cases should be alway IOOBE thrown, what is documented now also. I guess this is the similar case like we solved a time ago with declaring some type of unchecked excpetion which could be thrown what wasn't declared before but could happen. We decided not to put a state an incompatible change was made. What do you think? (Added Yarda to cc to get his opinion as well if needed).
OK, I still think it should be listed in apichanges with the above explanation, need not be marked incompatible.
Done: openide/api/doc/changed/apichanges.xml [1.33]
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.